How to detect if the host has changed a param?


AudioProcessorListener::audioProcessorParameterChanged is called each time a parameter is changed from Processor, but not if the host change a parameter... 

Before juce 3.2, I used AudioProcessor::setParameter to put some code to update audio variable updates or something else. But now I'm using the new AudioProcessorParameter class.

I am new to juce, surely I'm missing something obvious.


mmh an ugly hack, I had to change AudioProcessor::sendParamChangeMessageToListeners to public, and call it in my param class to call sendParamChangeMessageToListeners from setValue()...

Is there a correct way to do it without changing juce?




Rail, thank for your response, but it's not what I'm looking for,

Now setParameter is setValue in the param, I'm looking a simple way to to know when the host changes a param inside the processor


I would also like an answer to this. I'm pretty much at a standstill until there is one.


There is nothing stopping you from forwarding the AudioProcessorParameter's setValue callback to your AudioProcessor. All you need to do is to have your AudioProcessorParameter subclass store a pointer to your AudioProcessor.

I have little sample code on a private repo which does exactly this. It will call a changeParameter method on the AudioProcessor which does nothing in my code but could re-calculate some DSP if necessary.


Thanks Fabian, I do not call to ProcessorEditor from setParameter/setValue, I have solved this way: I created a Listener on my BaseParam, so AudioProcessor inherits from BaseParam::Listener, it calls PluginAudioProcessor::onParamChange(BaseParam *param), no locks no threads... it calls from parameter::setValue(), I don't know if it is the correct way for update coefficients witch complex and heavy maths...

To comunicate to Gui, I use timercallback from Editor.


Are you allocating memory everytime a plugin parameter is changed?

That just seems, well, horrible...
I know it's just example code, but someone could copy and re-use that.

Please reconsider that implementation.


Thanks falkFX! Your absolutely right. I've changed the code and my post accordingly.