Again, I don't agree, I'm sorry. Ampdb() does not express
amplitudes in any system, as far as I can see, but just converts
a ratio into the SPL scale (which is expressed as 20log10(ratio)).
This can be applied to any input.

Victor


----- Original Message ----- 
From: "Julian Peterson" 
To: 
Sent: Tuesday, January 06, 2009 1:37 AM
Subject: [Csnd] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: dynamic range


> You're right, of course; I only mean deprecated in the sense that  ampdb
> is designed to express amplitude in a 16 bit system, which is a
> disappearing standard, and that it is completely replaced by using the
> much more flexible 0dbfs and ampdbfs.
>
> Just not sure why there is continued hullabaloo over this...
>
> JP
>
>
>
> On Jan 5, 2009, at 1:46 PM, victor wrote:
>
>> But ampdb is not deprecated. It correctly applies
>> the 20Log10(x) expression!
>>
>> Victor
>>
>>
>> ----- Original Message ----- From: "Julian Peterson"
>> > >
>> To: 
>> Sent: Monday, January 05, 2009 7:02 PM
>> Subject: [Csnd] Re: Re: Re: Re: Re: Re: Re: Re: dynamic range
>>
>>
>>> Why not assume that ampdb is deprecated and inaccurate for  historical
>>> reasons, and use ampdbfs instead?  This seems like a  solution that
>>> doesn't require any additional labor or argument;   nor does it run the
>>> risk of violating backward compatibility.
>>>
>>> In other words: why not use the elegant solution already in place?
>>>
>>>
>>> JP
>>>
>>>
>>>
>>>
>>> On Jan 5, 2009, at 11:06 AM, Partev Barr Sarkissian wrote:
>>>
>>>> "And one cannot change existing opcodes as it runs the danger of
>>>> breaking
>>>> existing music" - Okay, assume that's a given.
>>>>
>>>> Could you simply take "ampdb" and have that as a starting point,
>>>> something like;
>>>>
>>>> asig1  (whatever opcode)  whatever parameters    <= declared
>>>> againstage  ampdb   asig1*(and its parameters)   <= declared
>>>> iamp   =  againstage*(some factor or coefficient)<= adjusted  amplitude
>>>> asig2  =  iamp                                   <= new adjusted
>>>> signal
>>>>
>>>> ... and adjust it to where you want it. Is that do'able?
>>>>
>>>> -Partev
>>>>
>>>>
>>>> = = = = = = =  = =
>>>> ====================================================================
>>>> = = = = = = =  = =
>>>> ====================================================================
>>>>
>>>>
>>>> --- jpff@cs.bath.ac.uk wrote:
>>>>
>>>> From: jpff@cs.bath.ac.uk
>>>> To: csound@lists.bath.ac.uk
>>>> Subject: [Csnd] Re: Re: Re: Re: Re: Re: dynamic range
>>>> Date: Sun, 21 Dec 2008 16:12:04 -0000 (UTC)
>>>>
>>>> And one cannot change existing opcodes as it runs the danger of
>>>> breaking
>>>> existing music.
>>>>
>>>>> Why? That does not make any sense to me.
>>>>> ----- Original Message -----
>>>>> From: "Federico Vanni" 
>>>>> To: 
>>>>> Sent: Sunday, December 21, 2008 2:57 PM
>>>>> Subject: [Csnd] Re: Re: Re: Re: dynamic range
>>>>>
>>>>>
>>>>>> ok Alan, thanks...
>>>>>> so why we don't change the 'ampdb' opcode using
>>>>>> a maximum dB value of 96???
>>>>>> it should be more accurate teorically...
>>>>>> best
>>>>>> fv
>>>>
>>>>
>>>>
>>>>
>>>> Send bugs reports to this list.
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>>>> "unsubscribe csound"
>>>>
>>>>
>>>>
>>>>
>>>> _____________________________________________________________
>>>> Netscape.  Just the Net You Need.
>>>>
>>>>
>>>> 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"
>>
>>
>>
>> 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"

victor wrote:
> Again, I don't agree, I'm sorry. Ampdb() does not express
> amplitudes in any system, as far as I can see, but just converts
> a ratio into the SPL scale (which is expressed as 20log10(ratio)).
> This can be applied to any input.
> 


It's simply a matter of the range, and the reference value.

20. *  log10(32767) ~= 90.3

Except that  "by convention" 32767 was defined as Csound's maximum 
positive value before clipping; i.e. it posits a 16bit sample range 
(which is why some people still seem to thiunk Csound is somehow a 16bit 
system).  Whereas the global audio industry standard is to define that 
as 0dBFS. If we therefor want to express a level in industry terms of 
-6dB,  we know that would be 16384;  but the formula above gives it as 
84.2.  That is how the usage was defined in the original manual.

Hence  the ampdbfs pair, to express all levels relative to digital peak 
= 0dBFS. And subsequently the 0dbfs opcode itself, intended finally to 
render the old 16bit representation obsolete and (ideally) deprecated. 
The mathematics is not in question; the choice of reference level is. 
The new opcodes  simply enabled Csound to express itself in a way 
exactly compatible with industry practice.

Richard Dobson

Well, I suppose it all depends on the use. In my mind, I would use ampdb(x) to
set up gain controls. So

...
kgain = ampdb(kdb)          ; eg if kdsb = -6
          out asig*kgain           ; then kgain = 0.5 (rounded-up)

For instance, I use that to set up the relative amplitudes of formants from
a vowel-formant table. That is why I can't see this as deprecated.

Just to make my point clear (and I promise this is the last post of mine on
the issue...).

Victor

At 10:11 07/01/2009, you wrote:
>victor wrote:
>>Again, I don't agree, I'm sorry. Ampdb() does not express
>>amplitudes in any system, as far as I can see, but just converts
>>a ratio into the SPL scale (which is expressed as 20log10(ratio)).
>>This can be applied to any input.
>
>
>It's simply a matter of the range, and the reference value.
>
>20. *  log10(32767) ~= 90.3
>
>Except that  "by convention" 32767 was defined as Csound's maximum 
>positive value before clipping; i.e. it posits a 16bit sample range 
>(which is why some people still seem to thiunk Csound is somehow a 
>16bit system).  Whereas the global audio industry standard is to 
>define that as 0dBFS. If we therefor want to express a level in 
>industry terms of -6dB,  we know that would be 16384;  but the 
>formula above gives it as 84.2.  That is how the usage was defined 
>in the original manual.
>
>Hence  the ampdbfs pair, to express all levels relative to digital 
>peak = 0dBFS. And subsequently the 0dbfs opcode itself, intended 
>finally to render the old 16bit representation obsolete and 
>(ideally) deprecated. The mathematics is not in question; the choice 
>of reference level is. The new opcodes  simply enabled Csound to 
>express itself in a way exactly compatible with industry practice.
>
>Richard Dobson
>
>
>
>Send bugs reports to this list.
>To unsubscribe, send email sympa@lists.bath.ac.uk with body 
>"unsubscribe csound"

Victor Lazzarini
Music Technology Laboratory
Music Department
National University of Ireland, Maynooth 

Victor Lazzarini wrote:
> Well, I suppose it all depends on the use. In my mind, I would use 
> ampdb(x) to
> set up gain controls. So
> 
> ...
> kgain = ampdb(kdb)          ; eg if kdsb = -6
>          out asig*kgain           ; then kgain = 0.5 (rounded-up)
> 
> For instance, I use that to set up the relative amplitudes of formants from
> a vowel-formant table. That is why I can't see this as deprecated.
> 
> Just to make my point clear (and I promise this is the last post of mine on
> the issue...).
> 


To be clear in my own turn, I mean 'deprecated" strictly with respect to 
~defining~ signal levels, not with respect to general  arithmetic 
modification such as you demonstrate (indeed ampdb is useful in that way 
precisely because it does not take 0dbfs into account). The issue for me 
is in using ampdb and its kin to ~set~ the level e.g. for oscil, linseg, 
etc - or for your asig above.

old practice:

asig oscil ampdb(84),440,1  ; assumed 16bit range

new practice:

; 0dbfs = 1  ; we would use this too, ideally, ampdbfs uses it

asig oscil ampdbfs(-6),440,1

And so on.




Richard Dobson