Program-Dependent JUCE Stock Compressor

Hi everyone,

I am trying to make the JUCE stock compressor program dependent using crest factor. I have the time calculation set up like the following. Each time I use the actualAttackTime or actualReleaseTime, the mono versions of my plug-in stop passing audio. I can’t figure out why this would be. Do you all have any ideas?

//Declare variables
float crestFactor = 0.0f;
float selectedAttackTime = 30.0f;
float selectedReleaseTime = 100.0f;

//Calculate average crest factor between the channels 
for ( int channel = 0; channel < totalNumInputChannels; ++channel){
crestFactor += (buffer.getMagnitude(channel, 0, numSamples) / buffer.getRMSLevel(channel, 0, numSamples)) / totalNumInputChannels;}

//Modify the selected release time and store it as the value for the compressor
float actualAttackTime = selectedAttackTime / (crestFactor - 0.5f);
float actualReleaseTime = selectedReleaseTime / (crestFactor - 0.5f);

//Set the compressor's settings
comp.setAttack(actualAttackTime);
comp.setRelease(actualReleaseTime);

Thank you,
Andy

I can’t say why mono won’t work but this is what I noticed in your code:

  • On silent input getRmsLevel() will be zero, resulting in crestFactor becoming infinity
  • Is float actualAttackTime = selectedAttackTime / (crestFactor - 0.5f); really what you want to do? With crestFactor == 0.5 the code will divide by zero which probably won’t occure but still isn’t ideal.
  • The RMS size depends on the buffer size resulting in differen behavior depending on the hosts audio settings.

The way to fix this issues is the debugger: Step through the processing while keeping a look at the audio samples buffer. If the sample values become ‘invalid’ (inf, NaN or very large) try to find out where that happens.

1 Like

Thank you! Is there away to force NaN to become a 1? I am running into problems with NaN, and I would hope not to change the fact that I am using crest factor in this design.

You can use std::isnan, std::isinf or std::isfinite and set everything to an arbitrary value but this is generally a rather bad approach. It is better to look why you get NaN or Inf and avoid this in the first place.

Gotcha! Thank you.