The documentation says:
The host will call this method to change the value of a parameter. The host may call this at any time, including during the audio processing callback
From which thread is this call made? I guess not the GUI thread, but is it the audio thread (as in the same from which processBlock is called), or it could be some other one?
Also, if the host calls setValue, and setValueNotifyingHost also calls setValue, how do we separate a change coming from inside the plugin (say, the GUI) from another coming from the host?
Sorry for the newbie questions -I’ve wandered all around the docs and still can’t get my head around this stuff…
In most hosts this is the audio thread, updating all parameters before calling processBlock, so that it would be safe to use.
However, it is not guaranteed, e.g. ProTools was reported to have a dedicated thread for parameter updates.
Thanks, noted. I still don’t know where to start for updating controls from host automation though. Can you point me somewhere to look? I’ve read the reference many times and I still don’t get it. The only thing I can think of is setting a flag when a GUI control is changed to avoid it updating itself… It looks a lot like I’m missing something.
EDIT: I think this answers it, if it’s still up-to-date.
Ok, so the thing that thread misses is, that the host has full control over the values. Your GUI must not set values directly. The reason for that is, that the host can have different automation modes, usually: Read, Write, Latch and Off. If the automation is set to Read, the changes in your UI shall have no effect. Or in latch, the host has to be notified, when you start touching the fader, which is done by sending parameter.beginChangeGesture() and finish with endChangeGesture().
Your UI calls setValueNotifyingHost, so the host can decide what to do, and if applicable, it responds with a parameter.setValue().
If you use the AudioProcessorValueTreeState and the SliderAttachment/ButtonAttachment/… this is all handled automagically.
Another thing, that plays a role are control surfaces, they act like your UI, but talk directly to the host and modify the values, not via your editor.
Oh… it’s starting to make sense… So what would be the actual in/out points across all this, ValueTreeState - Parameter - Attachment - Component? I mean, in the simpler situations all the chain of DragStarted/Ended - ValueChanged - begin/endChangeGesture - setValueNotifyingHost would work by itself and I just get values from ValueTreeState::Listener::parameterChanged?