Hi all,

The opcode arguments for 'compress' look like this:

  ar compress aasig, acsig, kthresh, kloknee, khiknee, kratio, katt,
krel, ilook

Assuming that I use an identical signal for aasig and acsig, would there
be any values that could give a totally unmodified output signal?  (such
that ar == aasig == acsig)

I have tried kthresh = 0, kloknee = 0, khiknee = 0, kratio = 1, but my
test signal (beats.wav) is still digitally different (though it sounds
identical to me).  I'm guessing katt, krel, and ilook will be immaterial
in this situation.  I also tried very high values for the knee, but no
luck.  Is this possible?  It's pretty much academic as I can special
case for the clean output and not apply the opcode, but I'm interested
to know why it's not possible in any case.

Cheers,
David



Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

I'm not 100% sure, as I don't know the internals of the opcode,
but I'd be surprised if you can get a true bypass inside the opcode.
It seems to be a compressor with a sidechain input,
maybe you can use a stable signal (sine with static amp) as acsig, and
that would disable the sidechaining ?
It would be interesting to hear what Mr Vercoe himself could tell us about it.
best
Oeyvind

2011/5/19 David Banks :
> Hi all,
>
> The opcode arguments for 'compress' look like this:
>
>  ar compress aasig, acsig, kthresh, kloknee, khiknee, kratio, katt,
> krel, ilook
>
> Assuming that I use an identical signal for aasig and acsig, would there
> be any values that could give a totally unmodified output signal?  (such
> that ar == aasig == acsig)
>
> I have tried kthresh = 0, kloknee = 0, khiknee = 0, kratio = 1, but my
> test signal (beats.wav) is still digitally different (though it sounds
> identical to me).  I'm guessing katt, krel, and ilook will be immaterial
> in this situation.  I also tried very high values for the knee, but no
> luck.  Is this possible?  It's pretty much academic as I can special
> case for the clean output and not apply the opcode, but I'm interested
> to know why it's not possible in any case.
>
> Cheers,
> David
>
>
>
> Send bugs reports to the Sourceforge bug tracker
>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>
>


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

It could be the lookahead time, which delays the signal by the specified time.
Even if this is set to 0, there is a one sample delay.

I checked with the same parameters you described, and after correcting this
one sample delay, the values were very nearly identical, and were actually
identical after the first few samples.

There is another curious anomaly that I discovered while checking this, which
is that this opcode seems to use hardcoded amplitude values. Using 0dbfs = 1
causes compress to output silence in every case.

Regards,
 - Joel

On 19 May 2011 23:50, Oeyvind Brandtsegg  wrote:
> I'm not 100% sure, as I don't know the internals of the opcode,
> but I'd be surprised if you can get a true bypass inside the opcode.
> It seems to be a compressor with a sidechain input,
> maybe you can use a stable signal (sine with static amp) as acsig, and
> that would disable the sidechaining ?
> It would be interesting to hear what Mr Vercoe himself could tell us about it.
> best
> Oeyvind
>
> 2011/5/19 David Banks :
>> Hi all,
>>
>> The opcode arguments for 'compress' look like this:
>>
>>  ar compress aasig, acsig, kthresh, kloknee, khiknee, kratio, katt,
>> krel, ilook
>>
>> Assuming that I use an identical signal for aasig and acsig, would there
>> be any values that could give a totally unmodified output signal?  (such
>> that ar == aasig == acsig)
>>
>> I have tried kthresh = 0, kloknee = 0, khiknee = 0, kratio = 1, but my
>> test signal (beats.wav) is still digitally different (though it sounds
>> identical to me).  I'm guessing katt, krel, and ilook will be immaterial
>> in this situation.  I also tried very high values for the knee, but no
>> luck.  Is this possible?  It's pretty much academic as I can special
>> case for the clean output and not apply the opcode, but I'm interested
>> to know why it's not possible in any case.
>>
>> Cheers,
>> David
>>
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>
>>
>
>
> Send bugs reports to the Sourceforge bug tracker
>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>
>


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

>
> There is another curious anomaly that I discovered while checking this,
> which
> is that this opcode seems to use hardcoded amplitude values. Using 0dbfs =
> 1
> causes compress to output silence in every case.
>
>

That needs to be fixed.  the code came from Barry who i think does not
have the 0DBFS change.

==John ff



Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Hi Joel,

On 19/05/11 23:17, Joel Ross wrote:
> It could be the lookahead time, which delays the signal by the specified time.
> Even if this is set to 0, there is a one sample delay.
> 
> I checked with the same parameters you described, and after correcting this
> one sample delay, the values were very nearly identical, and were actually
> identical after the first few samples.

Thanks!  I have confirmed this - for my sample after taking the delay
into account the values are indeed identical from the very start.  The
delay is not a big deal for me, so problem solved!

Cheers,
David



Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"