Just be careful with what we 'deprecate'. IMHO, ampdb() is
not deprecated (I have mentioned here some of its possible
applications).

Victor
----- Original Message ----- 
From: "DavidW" 
To: 
Sent: Wednesday, February 11, 2009 9:31 PM
Subject: [Csnd] Re: indicating deprecation (was Re: Re: rendering issues, 
0dbfs wonkiness (olpc))


> Indicating deprecation should be at the top of the entry - near the  name. 
> I'd vote against moving things out of alphabetical order into  some sort 
> of deprecation hierarchy: If you want to look up a feature,  want you want 
> is access to the info as simply as possible, without  having to wonder 
> where it might be located.
> D.
> On 12/02/2009, at 7:57 AM, Steven Yi wrote:
>
>> I'm all for Anthony's ideas here.  One thing is that I think currently
>> "deprecated" shows up at end of an opcode reference; it might be worth
>> placing notes on top of page if we can get that going.
>>
>> On Wed, Feb 11, 2009 at 12:53 PM, Anthony Kozar
>>  wrote:
>>> I think that it would be a good idea for Csound 6 to reorganize  section 
>>> II
>>> of the manual ("Opcodes Overview") so that the currently  recommended 
>>> opcodes
>>> in each section are presented first and older unrecommended,  confusing, 
>>> or
>>> broken opcodes be placed in a "deprecated" section further down in  each
>>> section or on an entirely different page.  Perhaps even a page with  a 
>>> table
>>> of "unrecommended" opcodes and a "use instead" recommendation.   Heck, 
>>> why
>>> not stick a note on the reference pages for each of those opcodes 
>>> saying the
>>> same thing.
>>>
>>> At the same time, we could move many of the obsolete or  "unrecommended"
>>> opcodes into a compatibility plugin that would perhaps not be  loaded by
>>> default.
>>>
>>> One of these days, I will set up the tool chain for the manual on my
>>> computer and get to work ...
>>>
>>> Anthony Kozar
>>> mailing-lists-1001 AT anthonykozar DOT net
>>> http://anthonykozar.net/
>>>
>>> Richard Dobson wrote on 2/11/09 4:48 AM:
>>>
>>>> You have hit the eternal Csound problem of changes and additions of
>>>> opcodes (that in various ways encourage new ways of thinking), while
>>>> retaining all the old ones for backwards compatibility. One  solution 
>>>> may
>>>> be a general "compatibility" section in the manual somewhere, that
>>>> collates all these changes - there is a number of opcodes still in  the
>>>> system that have been substituted by newer enhanced (or even 
>>>> corrected)
>>>> ones.
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe 
> csound" 

ampdb( ) is absolutely NOT deprecated - you need to be careful when  
you use it WITH 0dbfs

-db( )


On Feb 11, 2009, at 5:21 PM, victor wrote:

> Just be careful with what we 'deprecate'. IMHO, ampdb() is
> not deprecated (I have mentioned here some of its possible
> applications).
>
> Victor
> ----- Original Message ----- From: "DavidW" 
> To: 
> Sent: Wednesday, February 11, 2009 9:31 PM
> Subject: [Csnd] Re: indicating deprecation (was Re: Re: rendering  
> issues, 0dbfs wonkiness (olpc))
>
>
>> Indicating deprecation should be at the top of the entry - near  
>> the  name. I'd vote against moving things out of alphabetical order  
>> into  some sort of deprecation hierarchy: If you want to look up a  
>> feature,  want you want is access to the info as simply as  
>> possible, without  having to wonder where it might be located.
>> D.
>> On 12/02/2009, at 7:57 AM, Steven Yi wrote:
>>
>>> I'm all for Anthony's ideas here.  One thing is that I think  
>>> currently
>>> "deprecated" shows up at end of an opcode reference; it might be  
>>> worth
>>> placing notes on top of page if we can get that going.
>>>
>>> On Wed, Feb 11, 2009 at 12:53 PM, Anthony Kozar
>>>  wrote:
>>>> I think that it would be a good idea for Csound 6 to reorganize   
>>>> section II
>>>> of the manual ("Opcodes Overview") so that the currently   
>>>> recommended opcodes
>>>> in each section are presented first and older unrecommended,   
>>>> confusing, or
>>>> broken opcodes be placed in a "deprecated" section further down  
>>>> in  each
>>>> section or on an entirely different page.  Perhaps even a page  
>>>> with  a table
>>>> of "unrecommended" opcodes and a "use instead" recommendation.    
>>>> Heck, why
>>>> not stick a note on the reference pages for each of those opcodes  
>>>> saying the
>>>> same thing.
>>>>
>>>> At the same time, we could move many of the obsolete or   
>>>> "unrecommended"
>>>> opcodes into a compatibility plugin that would perhaps not be   
>>>> loaded by
>>>> default.
>>>>
>>>> One of these days, I will set up the tool chain for the manual on  
>>>> my
>>>> computer and get to work ...
>>>>
>>>> Anthony Kozar
>>>> mailing-lists-1001 AT anthonykozar DOT net
>>>> http://anthonykozar.net/
>>>>
>>>> Richard Dobson wrote on 2/11/09 4:48 AM:
>>>>
>>>>> You have hit the eternal Csound problem of changes and additions  
>>>>> of
>>>>> opcodes (that in various ways encourage new ways of thinking),  
>>>>> while
>>>>> retaining all the old ones for backwards compatibility. One   
>>>>> solution may
>>>>> be a general "compatibility" section in the manual somewhere, that
>>>>> collates all these changes - there is a number of opcodes still  
>>>>> in  the
>>>>> system that have been substituted by newer enhanced (or even  
>>>>> corrected)
>>>>> ones.
>>
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>> "unsubscribe csound"
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"