Are getStateInformation() and setStateInformation() always called on the audio thread?

Are AudioProcessor::getStateInformation() and AudioProcessor::setStateInformation() always called on the audio thread? Or can they be called from e.g. a random thread on the host while a concurrent call to AudioProcessor::processBlock() is in progress?

Which methods on an AudioProcessor instance are guaranteed to be only called from the audio thread?

More often than not they are called from the message thread, the only host I know to call from some other thread is protools. So you have to assume some cross thread chaos at some point. That’s why apvts has those handy threadsafe replace state and copy state calls.

Ok thanks.

I am working on a modular synthesis plugin, in which the user will be adding and removing eurorack-style “modules” – oscillators, filters and the like, and wiring them up as they see fit. This means that the value tree in my plugin is more of a “value directed cyclic graph” that is changing frequently.

AudioProcessorValueTreeState seems to want to have all its parameters defined at instantiation time, so sadly I don’t think I can use it. I’m working on rolling my own system to manage state instead.

Edit: unless there is a way to do this with apvts or some other part of the juce framework?..

The problem is not APVTS, it is juce in general, which doesn’t allow dynamically changing the parameters.
The reason is that the hosts are not handling it in a consistent way.

On the original question it is never the audio thread, but can be any thread as was mentioned before

I use my own little non-blocking FIFO buffer to store parameter changes from ‘parameterChanged’, that way I can grab any changes at the start of each process block, by emptying the buffer into the correct places.
It’s a slight detour but I find it useful, and it’s good to know my internal parameters are always changed in the same place.

DaveH: Yep, I’m concocting something similar