JUCEApplication Parameters Conventions

Development
1

When writing a plugin i create a AudioProcessorValueTreeState class member on the PluginProcessor class and then pass it to the editor that is created by the processor

like this:

AudioProcessorEditor* MyAudioProcessor::createEditor()
{
return new MyAudioProcessorEditor(*this, m_vts);
}

When writing a JUCEApplication there no AudioProcessor, instead there is a getNextAudioBlock
function on the MainComponent that gets called on a real time thread.

How should i implement parameters in a JUCEApplication? should i create a class that inherits from AudioProcessor and then attach the AudioProcessorValueTreeState to it and then pass it back to the MainComponent? or is there a different way?

2

The main purpose of the AudioParameterXYZ classes is to communicate to the host, including keeping responsibility for the ultimate value at the host (depending on the automation setting or hardware controllers, the host has the last say).
The other thing those parameters handle are the beginChangeGesture and endChangeGesture (also related to the automation responsibilities).

Both things don’t occur in a JUCEApplication, so the only thing to deal with is concurrent access of GUI and audio thread. To handle that wrapping the value into a std::atomic is enough.