I implemented my plugin host in a way so that it takes care of passing the parameter changes from the plugin editor to the audio processor through IParameterChanges and ProcessContext.
Now I’m working on automation, and I’m wondering: is it the expected behaviour that, if I pass in parameter changes that are NOT coming from the UI, but from some form of automation, the opaque state that I get the next time I call the IComponent::getState method, will change, just as if I had changed the parameter in the UI ?
Or is the expectation that the opaque state only changes if a user manually changes a parameter?
The part about sending the automation changes to the controller always confuses me because it seems like the plugins I’m testing with update the editor even without explicitly updating the UI controller …
This is the job of the host to sync parameters between processor and controller…
the processor could process in advance, for example 1s, and the controller should be updated when the audio reached the speakers (in the UI-Thread) for updating the UI elements.
If a plugin updates its UI from the processor, this is wrong… this could be done for some specific data like FFT computed in processor and sent to the controller with a timestamp.
Some frameworks like JUCE treat the Editor and Processor not as two distinct objects, but as a single ‘monolithic’ object. i.e. sending a parameter update to the Processor is effectively the same as sending it to the Editor. JUCEs behaviour is a hangover from the VST2 era, and is not best practice.
Other frameworks like SynthEdit maintain a clean separation of concerns between the Editor and Processor. And need both to be notified of parameter automation. So it’s safest not to assume that all plugins function like JUCE.