Just one aspect from practical experience to add to the discussion: One of my key issues with presets is portability: I replicate my Cantabile racks and songs between three machines (studio, live, backup) via Dropbox; a mechanism that allows me to keep presets/vst configurations within song/rack files makes my life immensely easier.
A lot of synths have moved to their own preset management systems, using preset files folders somewhere in the local file system (Documents, AppData, ProgramData), which makes synchronizing presets between my systems a pain.
One specific pain point is Korg M1 - it switches out the complete preset bank it exposes whenever you use a preset from a different “card”, but of course Cantabile doesn’t know that. So using the internal preset model is only usable in a very constrained way (stay within one “user” bank, copy everything there, don’t use performance mode…).
These days, I mostly use “Entire bank” state behavior for those complicated synths and a number of other plugins. As long as I don’t get switch time issues, this works nicely - with the exception of some plugins, e.g. Fabfilter Q 2 that creates clicks when loading states, even when nothing changes.
For plugins with full bank issues, or for instruments where I need smooth transitions, I mostly get by with state behavior of the relevant parameters as “light presets”.
Since I hide all this mess within racks anyhow, things look pretty nice at song level - but of course having this behavior pre-coded in plugin preset variants would be very helpful and clean up the inside of my racks!
This all looks great, and really makes it a lot clearer what’s going on. I particularly like the way you can extract a patch from a plugin and store it as a parameter set, including the name.
One additional thought - how about giving Cantabile some knowledge of many of the commonly used plugins, so that it can select a good default preset model? Or perhaps add a little label to the verbose preset modes dialog saying “(Recommended)” by the model deemed to be the most suitable?
There seems to be a trend in plugins in general and VST 3 plugins in particular to leave preset management up to the host. This manifests in a couple of ways such as plugins that don’t have any exposed preset system or plugins that expose presets but they can’t be edited - or they can be edited, but once you switch to another preset those changes are lost.
With Cantabile it’s quite common to want to switch sounds on a plugin. For traditional VST 2 plugins which have a built in bank of editable presets things work just fine. For plugins where there’s no exposed preset system Cantabile needs to provide a way to manage different sounds on the plugin.
providing a way to quickly switch or tweak sounds on a plugin by only adjusting its automatable parameters - rather than loading the entire plugin state which can be slow and often glitches.
Both of these problems currently have solutions in Cantabile:
The first problem of plugins with no exposed preset management is solved with pseudo-presets - the fake bank of presets that Cantabile simulates for plugins that don’t expose any presets. Another solution to this problem is the “Entire State” state behaviour.
The second problem of tweaking plugins via parameters can be done by enabling state behaviours for specific parameters - but that’s tedious because you need to explicitly enable the specific parameters and each state needs to be individually configured if you want the same sounds on multiple states.
“Preset Models” attempt to refine this in a few ways:
Making it more explicit which approach each plugin is using. Most people don’t even realize pseudo-presets are being used. While that’s good in a way, it also means users don’t really understand what’s happening.
Making the pseudo-preset functionality available on all plugins - not just those with no exposed presets - hopefully removing the need to use Entire State preset behaviour in some cases.
Providing an easier way to switch sounds with parameters that’s contained to the plugin - rather than depending on states.
@Torsten also makes an excellent point: consolidating preset settings into the song/rack so there’s no dependencies on external files makes things simpler to manage.
Having said all that… I very aware that all this seems more complicated than it should need to be - so I’m really keen to hear from anyone who finds this daunting.
Thanks @Torsten - that’s a really good point which I was aware of, but not actively thinking about in all of this.
That’s an interesting idea. I probably won’t do that to start with, but perhaps down the track some sort of community editable settings that define default behaviours for things like this would be cool.
Watching from afar with eyes wide, jaw dropped, and drool deposits in my beard. Brad is on fire. So much in so little time will have my head spinning for weeks…but I like that!
So glad I came back to Cantabile when v3 appeared. Where else do you see this amazing support from a developer, or a linked community of hospitable, considerate, and generous, well versed minds? True brilliance Brad !!
I really like that Preset Picker option.
Am I correct in thinking that the Picker is loading ALL parameters for the preset?
As an extreme example, could it call Kontakt presets in the same way that the Kontakt librarian does? i.e, all sample paths are saved/recalled?
Can a Picker bank be exported as a file for use in other Cantabile songs?
When the preset model is “Parameter Sets” each picker slot will hold a copy of every exported VST parameter from the plugin and Cantabile will store one copy of the plugin’s entire state that’s shared across all parameter sets. ie: everything that’s not exported by a parameter is shared across all parameter sets.
When the preset model is “Plugin Snapshot” each picker slot stores an copy of the entire plugin state.
Yep as a .cantabileBank file like it is now. That file is basically a copy of everything Cantabile saves for a song or rack for a plugin, including the entire state of the plugin (including the selected preset model and each picker slot content) + any morph/randomize settings that have been configured.
This morning I took a stab at resolving the import/export/copy/paste program issue I mentioned previously. The issue here is what to do if you export or copy a program in one preset model and try to import or paste it to a plugin with a different preset model setting.
In the end I took a fairly simple approach to it:
When you export or copy a program, regardless of which preset model you have selected it copies three sets of data: the program data, the bank data and the parameter set data.
When you import or paste a program, depending on the selected preset model it loads one of the three saved data sets and ignores the others.
The only down side to this is when importing to a plugin in “parameter set” preset mode it will only ever import the parameters and not the underlying plugin settings but I find that preferable to accidentally overwriting settings that the user has explicitly stated should be shared across presets. If you really want to import all the preset settings and not just the parameters you can still do it via a native preset file (ie: a .fxp file).
Note this also applies to the “Undo Program Changes” while in Parameter Set mode - it only ever undoes the parameter changes and not any other plugin settings.
Assuming I don’t find any fundamental problems while testing, this finishes preset model support. However, I’m not going to release it yet as I want to sit on it until the VST 3 work is finished just in case I need to make further changes.
Next up is more testing and then I think I can pop the development stack and return to Revisiting VST 3.
This will make my life a lot simpler, with all the different preset management systems of my various VSTIs. Will give it a thorough shake over the next weeks…
Me too, this is a really nice usability enhancement!!
If you have a plugin in a rack, with lots of Entire Plugin / Parameter Set data stored in the rack, is there any nice way to export that data and import it into another instance of the plugin elsewhere?
Oh wow - Korg M1 is now a joy to use with snapshots. Set the first snapshot to a single prog from user bank, next snapshot to a multi from Card 1 - works like a charm. Love it!!!
