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
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 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