Looking at the manual I have two immediate thoughts

1:  It ought to refer to 0dbfs rather than 32768

2:  we could say positive dB as before (90db = 0dbfs, 0db whatever)
and negative db as we expect (0db = 0dbfs, -90dB as reality)

Would this work?  It seems compatible as the current version clearly
expects positive db

yeah, after some experimentation, knee values above 0 does seem to be
correct, though not far above 0 it seems. Certainly in my situation
the example values given seem to be far too high. I'm a little
confused by thought number 2, it reads like you're suggesting it
should be both?

I don't often work with db's, and I neglected compressors for ages in
my early production career, so it's maybe just my lack of
understanding here

On Fri, Jan 29, 2016 at 4:07 PM, jpff  wrote:
> Looking at the manual I have two immediate thoughts
>
> 1:  It ought to refer to 0dbfs rather than 32768
>
> 2:  we could say positive dB as before (90db = 0dbfs, 0db whatever)
> and negative db as we expect (0db = 0dbfs, -90dB as reality)
>
> Would this work?  It seems compatible as the current version clearly
> expects positive db
>

Sounds correct to me.
========================
Dr Victor Lazzarini
Dean of Arts, Celtic Studies and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

> On 29 Jan 2016, at 16:07, jpff  wrote:
> 
> Looking at the manual I have two immediate thoughts
> 
> 1:  It ought to refer to 0dbfs rather than 32768
> 
> 2:  we could say positive dB as before (90db = 0dbfs, 0db whatever)
> and negative db as we expect (0db = 0dbfs, -90dB as reality)
> 
> Would this work?  It seems compatible as the current version clearly
> expects positive db
> 

"2:  we could say positive dB as before (90db = 0dbfs, 0db whatever)
and negative db as we expect (0db = 0dbfs, -90dB as reality)"

what does that mean though? how can 90db and 0db both be 0dbfs? I know
I'm just missing something here, but what? lol

On Fri, Jan 29, 2016 at 4:20 PM, Victor Lazzarini
 wrote:
> Sounds correct to me.
> ========================
> Dr Victor Lazzarini
> Dean of Arts, Celtic Studies and Philosophy,
> Maynooth University,
> Maynooth, Co Kildare, Ireland
> Tel: 00 353 7086936
> Fax: 00 353 1 7086952
>
>> On 29 Jan 2016, at 16:07, jpff  wrote:
>>
>> Looking at the manual I have two immediate thoughts
>>
>> 1:  It ought to refer to 0dbfs rather than 32768
>>
>> 2:  we could say positive dB as before (90db = 0dbfs, 0db whatever)
>> and negative db as we expect (0db = 0dbfs, -90dB as reality)
>>
>> Would this work?  It seems compatible as the current version clearly
>> expects positive db
>>

You are right -- my suggestion has a flaw.  Still Someting like that -- 
looks like an optional arg or compress2 just like compress but with saner 
dB reference point.
==John

On Fri, 29 Jan 2016, Peter Burgess wrote:

> "2:  we could say positive dB as before (90db = 0dbfs, 0db whatever)
> and negative db as we expect (0db = 0dbfs, -90dB as reality)"
>
> what does that mean though? how can 90db and 0db both be 0dbfs? I know
> I'm just missing something here, but what? lol
>
> On Fri, Jan 29, 2016 at 4:20 PM, Victor Lazzarini
>  wrote:
>> Sounds correct to me.
>> ========================
>> Dr Victor Lazzarini
>> Dean of Arts, Celtic Studies and Philosophy,
>> Maynooth University,
>> Maynooth, Co Kildare, Ireland
>> Tel: 00 353 7086936
>> Fax: 00 353 1 7086952
>>
>>> On 29 Jan 2016, at 16:07, jpff  wrote:
>>>
>>> Looking at the manual I have two immediate thoughts
>>>
>>> 1:  It ought to refer to 0dbfs rather than 32768
>>>
>>> 2:  we could say positive dB as before (90db = 0dbfs, 0db whatever)
>>> and negative db as we expect (0db = 0dbfs, -90dB as reality)
>>>
>>> Would this work?  It seems compatible as the current version clearly
>>> expects positive db
>>>
>>> ==John ffitch

Also readng the code Victor scales the input t the 0ds value so the manual 
is wrong.

I am tending to a compress2 which is identical except ytreatment of the dB 
values


On Fri, 29 Jan 2016, jpff wrote:

> You are right -- my suggestion has a flaw.  Still Someting like that -- looks 
> like an optional arg or compress2 just like compress but with saner dB 
> reference point.
> ==John
>
> On Fri, 29 Jan 2016, Peter Burgess wrote:
>
>> "2:  we could say positive dB as before (90db = 0dbfs, 0db whatever)
>> and negative db as we expect (0db = 0dbfs, -90dB as reality)"
>> 
>> what does that mean though? how can 90db and 0db both be 0dbfs? I know
>> I'm just missing something here, but what? lol
>> 
>> On Fri, Jan 29, 2016 at 4:20 PM, Victor Lazzarini
>>  wrote:
>>> Sounds correct to me.
>>> ========================
>>> Dr Victor Lazzarini
>>> Dean of Arts, Celtic Studies and Philosophy,
>>> Maynooth University,
>>> Maynooth, Co Kildare, Ireland
>>> Tel: 00 353 7086936
>>> Fax: 00 353 1 7086952
>>> 
>>>> On 29 Jan 2016, at 16:07, jpff  wrote:
>>>> 
>>>> Looking at the manual I have two immediate thoughts
>>>> 
>>>> 1:  It ought to refer to 0dbfs rather than 32768
>>>> 
>>>> 2:  we could say positive dB as before (90db = 0dbfs, 0db whatever)
>>>> and negative db as we expect (0db = 0dbfs, -90dB as reality)
>>>> 
>>>> Would this work?  It seems compatible as the current version clearly
>>>> expects positive db
>>>> 
>>>> ==John ffitch
>> 

[responding to this discussion thanks to brief window of mobile 
connectivity here in rainy Carmarthen]:

I wrote the ~dbfs opcodes (and a little later the 0dbfs directive) 
umpteen years ago, expressly to move beyond the original system where, 
indeed, dB values went from zero (somehow) to 96dB max, as a direct 
mapping to Csound's then "usual"  32768 peak amplitude. Clearly a few 
legacy opcodes somehow embody that older system.  The idea of course was 
to establish a new standard practice/convention where digital maximum is 
represented by the value of 0dbfs, and dB values are then typically 
negative, as undestood everywhere else. All the while retaining 
backwards compatibility - which is why '0dbfs' still (and forever) 
defaults to 32768.

Richard Dobson



On 29/01/2016 16:26, Peter Burgess wrote:
> "2:  we could say positive dB as before (90db = 0dbfs, 0db whatever)
> and negative db as we expect (0db = 0dbfs, -90dB as reality)"
>
> what does that mean though? how can 90db and 0db both be 0dbfs? I know
> I'm just missing something here, but what? lol
>
> On Fri, Jan 29, 2016 at 4:20 PM, Victor Lazzarini
>  wrote:
>> Sounds correct to me.
>> ========================
>> Dr Victor Lazzarini
>> Dean of Arts, Celtic Studies and Philosophy,
>> Maynooth University,
>> Maynooth, Co Kildare, Ireland
>> Tel: 00 353 7086936
>> Fax: 00 353 1 7086952
>>
>>> On 29 Jan 2016, at 16:07, jpff  wrote:
>>>
>>> Looking at the manual I have two immediate thoughts
>>>
>>> 1:  It ought to refer to 0dbfs rather than 32768
>>>
>>> 2:  we could say positive dB as before (90db = 0dbfs, 0db whatever)
>>> and negative db as we expect (0db = 0dbfs, -90dB as reality)
>>>
>>> Would this work?  It seems compatible as the current version clearly
>>> expects positive db
>>>

@John Ah ok, cool. Sorry, it wasn't meant to be nit picking, just
couldn't figure out if I had misunderstood what you meant.

A compress2 does sound like a good option

On Fri, Jan 29, 2016 at 6:25 PM, Richard  wrote:
> [responding to this discussion thanks to brief window of mobile connectivity
> here in rainy Carmarthen]:
>
> I wrote the ~dbfs opcodes (and a little later the 0dbfs directive) umpteen
> years ago, expressly to move beyond the original system where, indeed, dB
> values went from zero (somehow) to 96dB max, as a direct mapping to Csound's
> then "usual"  32768 peak amplitude. Clearly a few legacy opcodes somehow
> embody that older system.  The idea of course was to establish a new
> standard practice/convention where digital maximum is represented by the
> value of 0dbfs, and dB values are then typically negative, as undestood
> everywhere else. All the while retaining backwards compatibility - which is
> why '0dbfs' still (and forever) defaults to 32768.
>
> Richard Dobson
>
>
>
>
> On 29/01/2016 16:26, Peter Burgess wrote:
>>
>> "2:  we could say positive dB as before (90db = 0dbfs, 0db whatever)
>> and negative db as we expect (0db = 0dbfs, -90dB as reality)"
>>
>> what does that mean though? how can 90db and 0db both be 0dbfs? I know
>> I'm just missing something here, but what? lol
>>
>> On Fri, Jan 29, 2016 at 4:20 PM, Victor Lazzarini
>>  wrote:
>>>
>>> Sounds correct to me.
>>> ========================
>>> Dr Victor Lazzarini
>>> Dean of Arts, Celtic Studies and Philosophy,
>>> Maynooth University,
>>> Maynooth, Co Kildare, Ireland
>>> Tel: 00 353 7086936
>>> Fax: 00 353 1 7086952
>>>
>>>> On 29 Jan 2016, at 16:07, jpff  wrote:
>>>>
>>>> Looking at the manual I have two immediate thoughts
>>>>
>>>> 1:  It ought to refer to 0dbfs rather than 32768
>>>>
>>>> 2:  we could say positive dB as before (90db = 0dbfs, 0db whatever)
>>>> and negative db as we expect (0db = 0dbfs, -90dB as reality)
>>>>
>>>> Would this work?  It seems compatible as the current version clearly
>>>> expects positive db
>>>>