Re: Automatic reloading of previously used settings
Posted: Wed Dec 04, 2019 12:21 am
Returning to the original request: it seems to me that part(s) of the specification may be missing or ill-conceived (for VST plugins, that is - the concept is sound for an executable).
Let's say I create a new project and insert the plugin, thus loading the "last used" settings. I now tweak these settings to better suit the project and save it. When I reload the project, should I expect the "per project" settings to be honoured; or should the "last used" settings be loaded (which may have been changed during work on another project in the meantime)?
Likewise, when loading a project, the plugin's settings are normally restored from the project file; if we are honouring "per project" settings, should these now be saved as the "last used", or should that happen only if I subsequently change a setting, or only when I explicitly request it, or at shutdown, or not at all because this isn't a "new" plugin instance?
The possibilities multiply if there might be multiple instances in the same project, maybe some "tweaked" and some not. How do we define "last used" if we tweak more than one of them? If we're saving at shut-down, can we trust the host to close the instances in a reliable order?
If the "last used" settings are intended for a plugin which is some kind of "global" processing for an entire studio, for which every project will use a single instance with the same settings (matching between listening environments, say), this would be no problem - just reload the current settings from disk every time the plugin starts up, and save the settings either on every change or at shutdown (a situation for which DaveyBoy is doing a grand job.)
However, if "per project" settings are to be honoured, the plugin will need some way to tell whether it is already part of a project or is a freshly added instance, which there's no built-in way to read AFAIK (not an FS limitation, just how VST works)*. The only way that I can see would be by preset number, so that, say, preset one is always the "last used" and has the current data re-loaded whenever the plugin is started up - but you would have to be sure to switch to a different preset before making any "per project" tweaks.
I can see the attraction of auto-loading to ease project setup, but the cost may not be worth it if we have to change how presets typically work such that there are other inconveniences, even just the need to remember that this plugin is an exception to the rules (an open invitation for unfortunate accidents!)
(* EDIT: I think a "new instance" test may be possible in a roundabout way, but it depends on how triggers from the preset manager are handled at startup and project loading - I'll have a little tinker; maybe possible, maybe not).
Let's say I create a new project and insert the plugin, thus loading the "last used" settings. I now tweak these settings to better suit the project and save it. When I reload the project, should I expect the "per project" settings to be honoured; or should the "last used" settings be loaded (which may have been changed during work on another project in the meantime)?
Likewise, when loading a project, the plugin's settings are normally restored from the project file; if we are honouring "per project" settings, should these now be saved as the "last used", or should that happen only if I subsequently change a setting, or only when I explicitly request it, or at shutdown, or not at all because this isn't a "new" plugin instance?
The possibilities multiply if there might be multiple instances in the same project, maybe some "tweaked" and some not. How do we define "last used" if we tweak more than one of them? If we're saving at shut-down, can we trust the host to close the instances in a reliable order?
If the "last used" settings are intended for a plugin which is some kind of "global" processing for an entire studio, for which every project will use a single instance with the same settings (matching between listening environments, say), this would be no problem - just reload the current settings from disk every time the plugin starts up, and save the settings either on every change or at shutdown (a situation for which DaveyBoy is doing a grand job.)
However, if "per project" settings are to be honoured, the plugin will need some way to tell whether it is already part of a project or is a freshly added instance, which there's no built-in way to read AFAIK (not an FS limitation, just how VST works)*. The only way that I can see would be by preset number, so that, say, preset one is always the "last used" and has the current data re-loaded whenever the plugin is started up - but you would have to be sure to switch to a different preset before making any "per project" tweaks.
I can see the attraction of auto-loading to ease project setup, but the cost may not be worth it if we have to change how presets typically work such that there are other inconveniences, even just the need to remember that this plugin is an exception to the rules (an open invitation for unfortunate accidents!)
(* EDIT: I think a "new instance" test may be possible in a roundabout way, but it depends on how triggers from the preset manager are handled at startup and project loading - I'll have a little tinker; maybe possible, maybe not).