I’m thinking of introducing a new plugin setting where the user can select between three different preset models.
Native - the plugin’s own preset model (possibly broken for some VST 3 plugins)
Plugin Snapshots - a bank of snapshots of the entire plugin state. Possibly slow, but captures everything between each preset. (These are currently known as pseudo-presets in Cantabile).
Parameter Snapshots - just captures the automatable parameters on a plugin. For some plugins these won’t be able to control every setting, but should provide super fast preset switching for plugins where it’s sufficient.
The main motivation for this is because the preset management of VST 3 plugins is a mess (see here) and Cantabile needs a way for users to wrangle better control of these plugins. VST 3 support doesn’t really need the parameter snapshots but that’s a closely related idea that seems appropriate to implement at the same time.
The bonus here is that if done correctly, you’ll all get more flexibility in controlling your existing VST 2 plugins too.
I need to think about this some more, but I’m definitely leaning towards implementing this.
I remember that some plugins create dropouts when using this command even if only an unimportant parameter was changed with the bank (f.e. changing the gain volume of a plugin or so).
Sort of. The second option is exactly the same as the current behaviour for VST 2 plugins that have only one preset slot. eg: if you load Kontakt into most hosts you’ll only see one preset slot is available. If you load it into Cantabile however you’ll see 128. That’s because Cantabile is simulating 128 presets by saving the entire plugin state into each preset slot. See here for full explanation.
Currently Cantabile automatically switches to this pseudo preset mode when a plugin only has one preset slot. This change is proposing instead to let the user select whether pseudo presets are used or not or, a new lightweight preset mode that only captures parameters.
As for “Entire Bank”… that’s a related but different option. That is state behaviour that says when switching states to save and restore the entire plugin state, including all presets. For a plugin like Kontakt that uses pseudo presets turning on Entire bank will save the entire plugin state ie: all 128 different preset slots. In general I no longer recommend using Entire Bank, because it’s an carry over from Cantabile 2 before psuedo presets were available and pseudo presets are a better, more manageable solution.
As for whether a plugin drops out or not… that’s mostly up to the plugin, but many will.
There sure is room for improvement indeed. I noticed that c3 take the plug-in presets and adds them to the internal. So they kinda get mixed up also. So would be good if they were split down. Like in reaper for example.
This sounds really interesting, and a welcome flexibility improvement. Option 3 is roughly how I run some of my plugins, such as VB3, where I store all my “presets” in rack states, with all the automation state behaviour checkboxes selected. It certainly is very fast, for plugins that provide sufficient automation. It would be great to have this functionality out of the box, rolled into a kind of pseudo preset style for ease of use.
Also interesting insight into “Entire Bank”. I’ve used this quite a lot as a brute force method to ensure my plugins get the same state back, but I didn’t realise it would be inefficient when applied to a plugin that uses pseudo presets. @brad, I wonder if it would be possible to add a warning to Setlist Verify, to alert you to the fact “Entire Bank” is being used on a such a preset, and so may be incurring unnecessary switching time, as well as file size?
Agree with @Neil_Durant on “check all the boxes”. Good for OBX, organs, etc. As far as “entire bank”, I started using this on the Korg products and maybe a few others some time ago. It would be disastrous with Kontakt, but the really fiddley instruments work pretty well. I’ve never gotten the hang of C3’s pseudo-presets. All that to say it’d be nice if there were options built in.
I must confess that how the current options work/differ has never been clear to me, but fortunately things have just worked for me so far. If I’m missing a good explanation could somebody please point me to it? If not then maybe going over it again with the new options as well would be a great help. Thanks.
Not really sure what that means. Which plugin exhibits this behaviour?
Can you post a screen shot showing this?
Sounds like a smart idea.
It probably won’t effect switching time because it essentially resolves down to a single bank load on the plugin, but could definitely affect file size time
I think the reason people struggle with this is because pseudo presets are mostly automatic, under the covers and so people don’t really see what’s happening. These changes I’m planning should make things a lot more explicit.
The blog post linked above is the current best explanation. After I finish this work I’ll write up some more detailed explanations in the guides.
The first task in implementing this is to centralize the pseudo preset management. Currently this is implemented as part of the VST 2 plugin hosting. So I spent this morning centralizing this to a common base class so it’ll be available for both VST 2 and VST 3 plugins.
Unfortunately the current pseudo-preset file format doesn’t have room for the longer VST 3 plugin id’s so I’ve had to invent a new file format that can handle the longer ids + ability to store parameter snapshots. This new file format will be invisible to users and old saved pseudo presets will be automatically updated to the new format on demand.
This also might mean Cantabile preset banks saved from newer builds of Cantabile (including songs using pseudo presets) won’t be loadable in older versions of Cantabile. I might make it switch back to the old format when saving if it’s a VST 2 plugin and it’s in pseudo preset compatible mode that way backwards compatibility will only be an issue if you’re using new functionality.
At the same time as centralizing this code I’m also adding support for saving parameter set snap shots (aka lightweight presets).
Overall this task is about 75% done and I’m hoping to have this bit finished by today/tomorrow.
Thanks again @brad for focusing on VST3 and the problems it rises.
Steinberg’s policy forcing VST3 is a pity for new plug-in developers and we want to be able to use all this new plug-in stuff in Cantabile, hahaha!
Progress… the old pseudo preset management code has been centralized in the common plugin hosting base class and should now work with VST 2 and 3 plugins and lightweight parameter set presets are implemented.
There’s still some questions there which I need to resolve about import/exporting programs when in different preset model modes. eg: what happens if you export (or copy) a preset when in one preset mode and try to import (or paste) when the plugin is in another. Not sure how to handle this yet.
In the meantime, started on some of the UI for this. Originally I was going to make the setting for this available via the right click menu on the plugin slot. However I wanted this to be more closely associated with the preset selector popup so I’ve added a little bar to the popup that shows the current preset model and has a “Change” button:
In order to really clarify what these preset modes mean I’ve made a fairly verbose dialog:
Besides the preset model, this dialog also lets you control how MIDI Program changes received by the plugin should be handled. This is equivalent to the old context menu option which will be removed:
Finally, in order to even further reinforce the different preset models, the default preset names have been updated to reflect the current model. ie: “Plugin SnapShot N” or “Parameter Set N”:
Next up is:
a bunch of testing
figuring out how to resolve copy/paste export/import of programs when in different preset models
a picker to allow changing the plugin’s internally selected preset when in either of the pseudo preset modes.
Some more progress today. Firstly, lots of testing… new preset models seems to be working nicely.
Next, I’ve added a new drop down in the plugin editor that lets you choose the plugin’s loaded preset when in one of the non-native preset model modes. eg: if you’ve selected to use Plugin Snapshots or Parameter Sets then you might want to load a preset from the plugin into one of those snapshots:
This picker also includes an option to copy the plugin’s internal preset name to Cantabile’s preset bank…
eg:
That gives me the weekend to think about how to handle import/export preset issues previously mentioned…
Are you suggesting this is too complicated? I’m a little worried about that and the “Let Cantabile Decide” option is to simply not go into these options - it should do something reasonable by default.
