From which thread(s) will an APVTS::Listener be called?

I’m building a plugin where plugin parameters will be used to control externally connected hardware. I’m managing the parameters through the AudioProcessorValueTreeState. Now if the parameters are changed by Sliders that are connected through SliderAttachements, I assume that the call to AudioProcessorValueTreeState::Listener::parameterChanged will be invoked by the messageThread. But what thread will call it when the parameter is changed by the DAW while playing back? May it be the real-time audio thread or another time-critical realtime parameter thread? Is this DAW-dependent behaviour or is there any behaviour that can be expected?

So all in all, should I take care of not doing my possibly time-consuming hardware-interaction directly in the Listener::parameterChanged callback but move it to a dedicated hardware-thread owned by my plugin instance or would this be unnecessary overhead?

By looking at the code it is called synchronously from setValue():

setValue itself is called from the host via SDK, so it is host dependant. I know from AAX, that it even has a dedicated Automation thread, see these forum threads: Automation firing early in Pro Tools 11 and Reminder: AAX setParameter is asynchronous -> use locking - #8 by Mayae

TL;DR don’t expect it to be the same for all situations.

I think this is a good idea in any case, if it is time consuming. Especially it seems the execution time will be determined by external hardware, if I understood that correctly.
While prototyping I managed to stall all drawing of my DAW even from inside the plugin…

1 Like

Thanks for your reply. I set up a quick’n dirty sketch plugin for a proof of concept where I called the hardware function directly in the callback. That worked as expected with ProTools but I think you are right that it’s much safer to do the hardware communication on my own thread, so I’ll be going that way.