JUCE Assertion failure in juce_AudioProcessor.cpp

Building a compressor i thought i did everything right,

I think it is to do with the process block or something in the cpp plug in processor section, ive mapped the parameters i thought with the sliderclass as it works visually but there are no audible changes

There are tons of assertions in the code that will make you notice if you did something wrong / unexpected, so with the information that some assertion is hit, we can’t help you very well. To help you best, you should tell us which assertion exactly is hit and maybe what you are doing with the plugin when it’s hit. Often, the assertion also has a comment block in the surrounding code, explaining you what might have gone wrong, in case that the assertion code itself is not that expressive.

2 Likes

Okay thank you for your reply. I’ll see what other information I can find, also it’s when I build the code

I just had a look at the code. You are right that you connected your audio parameters to your sliders. However, there is no place in your code where you forward parameter changes to your compressor instance – how do you expect your compressor to know that e.g. the "THRESHOLD" parameter you created should control the instance? You are definitely missing some mechanism to connect the parameters with the compressor instance :wink:

On e option to achieve that is that you add two pointers the underlying raw value of the parameters, which are stored as std::atomic<float>.

This would look like this in the private section of your PluginProcessor.h:

std::atomic<float>* thresholdRaw = nullptr;
std::atomic<float>* ratioRaw = nullptr;

Then in the constructor you can assign those pointers to point to the underlying parameter value of the parameter you created, like

thresholdRaw  = apvts.getRawParameterValue ("THRESHOLD");
ratioRaw      = apvts.getRawParameterValue ("RATIO");

Here you have to make 100% sure that the parameter ID string matches the one you used to create your parameter. It’s best to just store all parameter strings in a central header file and reference those variables each time instead of repeating it manually everywhere. Side-note: If you should have mis-spelled the ID, the function will return a nullptr instead of a pointer to the expected value. Since you don’t expect that to happen, you are best of adding your own assertion after these lines to make sure that you did no accidental mistake. Star using assertions in your own code is the best way to understand them in other peoples code I think :slight_smile: This would look like

thresholdRaw  = apvts.getRawParameterValue ("THRESHOLD");
ratioRaw      = apvts.getRawParameterValue ("RATIO");

// If any of these assertions are hit, the parameter ID string specified above doesn't match any existing parameter
jassert (thresholdRaw != nullptr);
jassert (ratioRaw != nullptr);

Now in each processBlock callback, you can load the current parameter value from the atomic and update the compressor accordingly before you are processing the next sample block, like


auto currentThreshold = thresholdRaw->load();
auto currentRation = ratioRaw->load();

// Here, the compressor finally is set to a value according to your current parameter value!
compressor.setThreshold (currentThreshold);
compressor.setRatio (currentRatio);

juce::dsp::AudioBlock<float> block (buffer);
juce::dsp::ProcessContextReplacing<float> context (block);
compressor.process (context);
2 Likes