Minor issue with AudioProcessorGraph when fast turning a plugin on and off. (Found by pluginval)

General JUCE discussion
3

Hi @w3rkhof,

Thank you for your replay. :slight_smile:

What do you mean by “audio system changes”? Changing a driver or buffer size, so releaseResources and prepareToPlay are called?

I think AudioProcessorValueTreeState could help here. At least I am using it and in the prepareToPlay method of my main processor I am calling a function which is initializing all processors from actual controls.

void DelaysAudioProcessor::initFromControlls()
{
    auto wetGain = dynamic_cast<GainAudioProcessor*> (wetGainNode->getProcessor());
    wetGain->setGainLinear(wetControll->get());
    
    auto dryGain = dynamic_cast<GainAudioProcessor*> (dryGainNode->getProcessor());
    dryGain->setGainLinear(dryControll->get());
...
}

By a control I mean:

private:
    AudioProcessorValueTreeState state;

    AudioParameterFloat* wetControll;
    AudioParameterFloat* dryControll;

which are initialized in main processor constructor:

    wetControll = dynamic_cast<AudioParameterFloat*> (state.getParameter("wet"));
    wetControll->addListener(this);

    dryControll = dynamic_cast<AudioParameterFloat*> (state.getParameter("dry"));
    dryControll->addListener(this);

And this works with my simple “tape” delay plugin. It could be a little bit harder to implement in a “Reactor”-like app, but AudioPluginHost form JUCE/extras could be an example of how to handle this, IMHO.

If I misunderstood you, I am sorry. Do not hesitate to correct me.
And please keep in mind that I am a noob, so I can be wrong. :stuck_out_tongue:

P.S.
Own editor for each node sounds cool. :slight_smile:
I think modular synths are now very popular.