I have a SingleComponentEffect plugin that uses shared memory to communicate with other instances of the plugin. Each instance of the plugin runs a timer on the UI thread and processes messages received from other instances of the plugin. In this way, one instance of the plugin can be used to “control” other instances of the plugin, by modifying parameters or other state, for example.
However, in WaveLab 11, there does not seem to be any way to persist state changes of plugins whose editors are not open. For example, imagine I have two instances of the plugin, one whose editor is open and one whose editor is not open, and I’m using the open editor to control both instances. There does not appear to be a way to update parameters on the instance whose editor is closed.
Here are the approaches that I have tried:
Using beginEdit(), performEdit(), endEdit() from the timer doesn’t work for an instance whose editor is not open, because WaveLab 11 does not call setComponentHandler() on such an instance.
Using ProcessData::outputParameterChanges from the audio processor’s process method in order to modify parameter values. This appears to be set to null for plugin instances whose editor is not open.
Storing the state internally (not in a parameter) and persisting the state via getState(). It seems that WaveLab does not call getState() unless it has reason to believe that the plugin’s internal state has changed. However, similar to #1, I am unable to call IComponentHandler2::setDirty() because no component handler has been provided by WaveLab.
When an audio montage opens, the edit controllers are not created, but for plugins with plugin automation.
When opening a plugin GUI and then closing it, the edit controller is not destroyed (but when the montage is closed).
@PG1 Thanks for the response. If the plugin has a parameter with the kCanAutomate flag, should the edit controllers be created, for example, so that the processor can modify parameters via outputParameterChanges? It seems like right now the controllers are not created in this case.
@PG1 I guess what I’m looking for is some way for the audio processor to signal to the host that its internal state has changed, so that getState() is called and its state can be persisted. Without such a mechanism, it seems like the host must assume that the audio processor’s internal state may have changed, and call getState() before closing the project.
You are right, and this is a valid intent. I wish there were a way for the plugin to notify a state change to the host. But there is no way of doing this, unfortunately, AFAIK.
In WaveLab, each time a plugin GUI is opened, getState is called by WaveLab to keep a copy, and when the plugin GUI is closed, getState is called again and compared to the original one. If the two states are different, the state is written in the WaveLab undo stack. Unfortunately, this is not a reliable mechanism because certain plugins don’t return the same binary state even if called twice in a row, while nothing was changed by the user in the GUI.
@Arne_Scheffler Based on this thread, would it make sense for a future update to VST3 to include the ability for an audio processor to indicate to the host that its internal state has changed, so that the host knows to call getState() in order to persist changes?
@PG1 In the meantime, would it make sense for WaveLab to call getState() on each plugin, regardless of whether or not its GUI has been opened, at least prior to saving the project?