Ryan Palm

So basically how do I make it so when you turn the gain up, that the output gain compensates accordingly?

I'm making a saturator for the Daisy Patch device and I want to make sure that I don't clip the headroom. First Idea was just a tanh to act as a sort of limiter, but that's going to affect the distortion algorithms...

So basically how do I make it so when you turn the gain up, that the output gain compensates accordingly?
I'm making a saturator for the Dai

i-want-to-gain-compensate-outputs-of-a-saturatordistortion

The gain you get from distortion depends on the crest factor of the input signal. There is no general formula to calculate it. You would have to measure the RMS level of input and output and compensate - but that means a delayed reaction.

I figured out a way to do it. Has to be done by hand, but I have routed the gain input parameter to a mixer object. Sandwiching that I have some scaler objects. By fine tuning the exponential response and accounting for 6dB of headroom on the hardware that is running the gen~ program, I was able to approximate a mixer factor that keeps the gain relatively the same without clipping the dac.

What would be the proper way to measure in/out rms and compensate gain? Delayed reaction is not really a problem in my case

you can just get the difference in power of input and output using [-~ ]

if you measured the power or the intensity with a window of 80 ms, you should delay the output for 40 ms before modulating it with the control signal.

but this will of course not take care about 5 ms fast transients. the more potential use cases you want to cover, the more you want to design it (==analysis speed and lookahead time) dynamically and leave them to the user.

note that inverting the controlsignal for such an autogain thing using !-~ will only work when there is a known upper limit. so maybe you want to add a hard clip at 1.0 or 2.0 or whatever. :)


you can just get the difference in power of input and output using [-~ ]

if you measured the power or the intensity with a window of 80 ms, you should delay the output for 40 ms before modulating it with the control signal.

but this will of course not take care about 5 ms fast transients. the more potential use cases you want to cover, the more you want to design it (==analysis speed and lookahead time) dynamically and leave them to the user.

note that inverting the controlsignal for such an autogain thing using !-~ will only work when there is a known upper limit. so maybe you want to add a hard clip at 1.0 or 2.0 or whatever. :)


I see, I will have to think about this in detail because I would prefer to keep it entirely in gen~.

Still, I'm not quite sure if I totally understand the concept of your solution. 

So first I subtract the in and out, the result is the difference in power. How would I go about setting the 80ms window for measurement, should I just use a [delay] operator and delay in samples?

After that I'm a bit lost, how should I apply the power difference to an auto gain? 

Still, I'm not quite sure if I totally understand the concept of your solution. 
So first I subtract the in and out, the result is the difference in power. How would I go about setting the 80ms window for measurement, should I just use a [delay] operator and delay in samples?

After that I'm a bit lost, how should I apply the power difference to an auto gain? 



I was working on another patch and found it worked alright to use dbtoa or atodb as part of the calculations. https://music.arts.uci.edu/dobrian/maxcookbook/pitch-and-loudness-formulae

interesting, Ryan! thanks, I will look into it. 

as for now, I got something like in this gen~ patch. It kinda works, until you push the processed gain over a value of 0.3, after that the auto gain is unreliable.

btw I used jayrope's RMS calculation method from here: peak-over-rms-pseudo-trigger-generator

interesting, Ryan! thanks, I will look into it. 

as for now, I got something like in this gen~ patch. It kinda works, until you push the processed gain over a value of 0.3, after that the auto gain is unreliable.

Does this look somewhat right to you?




btw I used jayrope's RMS calculation method from here: peak-over-rms-pseudo-trigger-generator

I found this in the documentation explaining how to use a buffer to take the average of the buffer and scale to a normalised value. 

https://docs.cycling74.com/max8/tutorials/15_delaychapter03

Now, I'm not quite sure if I understand how to measure RMS average in gen~. It doesn't seem to make a difference if the average RMS calculation code from Jayrope's post are in place or not.

is this even useful for comparing original signal vs processed signal to automatically compensate for gain?

The only thing it seems to be doing is compensating for changes in the [dbtoa] value. Where would I plug the processing in there?

I found this in the documentation explaining how to use a buffer to take the average of the buffer and scale to a normalised value. 

https://docs.cycling74.com/max8/tutorials/15_delaychapter03

Now, I'm not quite sure if I understand how to measure RMS average in gen~. It doesn't seem to make a difference if the average RMS calculation code from Jayrope's post are in place or not.

is this even useful for comparing original signal vs processed signal to automatically compensate for gain?
The only thing it seems to be doing is compensating for changes in the [dbtoa] value. Where would I plug the processing in there?

here is an example gen patch:

I want to gain compensate outputs of a saturator/distortion.