I’d like to request a feature: the ability to batch copy/paste a plugin (or plugin chain) across all tracks in Inspector > Track. This would make it easy to instance a plugin across many tracks at once.
The use case is Atmos projects, where a user might want the same plugin on every channel. Doing this manually for 28+ channels (and potentially 128 in larger projects) isn’t really viable.
Inserting the plugin in Inspector > Output isn’t a workable alternative for us, because the Output section links instances and shares a single saved state across all channels — and our plugin needs each instance to maintain its own independent state.
In case you’re wondering how a user would manage that many independent instances: our plugin already supports controlling multiple instances from a single “master” instance, so the user wouldn’t need to interact with each one individually — they just need them to exist on each track with their own persistent state.
What you can do is use the function to paste a plugin to all selected clips.
In an Atmos Master Montage, generally, there is a single clip on each track, so you get what you want.
But frankly, this is a strange user case for an Atmos montage.
This is something I am requesting too with the plugin developer meterplugs with their plugin Perception AB. I use this in stereo work flow a lot, but it doesn’t save setting in the inspector output in an atmos workflow.
I have tested your idea PG. I’m having an issue with Perception AB saving input (pre) setting on loading of a previous session. This isn’t an issue when initially setting the plugin up in the inspector. but upon saving, closing and reloading the session it looses all settings. This is a very common mastering AB plugin in stereo, it would be great if this could work in an atmosphere montage, there seems to be a limitation in the atmos montage that is stopping this plugin working. I’ve tried configuring the plug with the pre (all) channel on clip, tracks and output and I’m still having issues. The post channel is always on the output.
@PG1 I think @Gavin_McGrath is running into this issue that I raised in this thread:
In a nutshell, I don’t think WaveLab calls getState() for plugins whose editor is not open - is that right? Whereas Perception’s state can change even when its editor is closed. And so that state doesn’t get persisted with the project.
Would it be possible for WaveLab to call getState() on each plugin on project save, regardless of whether or not the plugin editor is / was open?
Sorry, but saving the state of each plugin each time audio montage is saved would be a performance regression to solve your very specific case.
Moreover, the case you describes seems very counter-intuitive to me: how the processor state could change without any user action? This does not match the VST philosophy as far as I know.
@PG1 Understood that performance might be an issue with that approach. I guess I’m at a loss for how to proceed. WaveLab is the only DAW we’ve encountered that exhibits this behavior of not persisting plugin state unless the editor was opened.
One option would be some sort of addition to the VST3 spec that would allow the plugin processor to inform the host that it’s state has changed and requires persisting on save (cc @Arne_Scheffler).
The context here is that Perception AB allows you to control all instances of the plugin from a single instance (e.g., “Bypass All”, “Match All”, etc.). This is necessary because the plugin can be used on many tracks / channels and it would be prohibitive to require the user to open each plugin separately to apply these actions.
This appears to be a bit of a grey area in the VST3 spec. I didn’t see any mention that a plugin’s state can only be manipulated via its editor, and it seems like getState() is the right place to persist this state.
@Arne_Scheffler In WaveLab, a plugin whose editor is not opened does not get an instance of IComponentHandler2 via setComponentHandler() (@PG1 correct me if I’m wrong about this).
Would it make sense to have a minimal interface passed to the plugin processor that would allow it to communicate state changes to the host? For example:
class IStateHandler : public FUnknown
{
public:
// Notify the host that the plugin's persistent state has changed
virtual tresult PLUGIN_API notifyStateChanged () = 0;
};
This is wrong: WaveLab calls setComponentHandler with IComponentHandler2 on any plugin used by an Audio Montage (but not when offline rendering).
WaveLab supports IComponentHandler2::setDirty, but WaveLab only tests the flag for the plugin whose editor has been opened.
And WaveLab only saves the state of plugins whose editor has been opened.
One solution would be for WaveLab to save the state of any plugin, provided the dirty flag has been set. But after looking at this possibility, this would require some non-negligible changes. Therefore, such a solution could not appear before WaveLab 14.
@PG1 Interesting, if I can get IComponentHandler2 in all instances of the plugin (even those that are not open), would it make any difference if I called beginEdit, performEdit, endEdit instead of setDirty? i.e., would WaveLab persist the parameter updates for those instances whose editors aren’t open?
I believe I had tried this back in WaveLab 11 but couldn’t get it to work - maybe the behavior has changed though?
If not, your idea of having WaveLab persist the state of any plugin, as long as setDirty has been called, seems like a good idea.
I think this is the correct way. If a plug-in tells the host that its state is dirty then the host should respect this and call getState() before saving.
This would not make a difference.
It works like this:
Before opening the plugin UI WaveLab gets the state.
When closing the UI we will gets the state again.
If the state are different (binary comparison), or if the dirty flag is set, WaveLab stores the new state.
This state tracking allows WaveLab to undo/redo plugin state change as part of any other audio montage edit. As far as I know, WaveLab is the only DAW that can do that.
