VST Preset models etc

Tags: #<Tag:0x00007f9777c19100> #<Tag:0x00007f9777c19010>

Good Morning,
could someone please share his (oder her? we’re a crowd of males, aren’t we? :wink: ) wisdom about handling presets with VSTs? I’m a little confused which model I have to use with the different VSTs. How do you ensure C3 always finds the presets again? Another issue: sometimes changing presets causes an annoying click. Maybe it would be helpful collecting our knowledge an expereiences for every VST we use in a sheet or something like that. Have a nice day!

1 Like

Hi Christoph,

I guess I’ll try to get the ball rolling. I’m certain there are many ways to do this but here goes.

I do a variety of things depending on the plugin. Discussing it at the song level with no racks the preset system of the plugin is tested by Cantabile to see what the best of the 3 choices would be best for the plugin involved.

If the plugin is fully VST2 compliant the plugin’s factory presets will automatically load onto the Cantabile preset slots on the plugin slot “Use Plugin’s Programs”. The plugin’s file manager in this case is where the preset parameters are and Cantabile finds it by assigning a Cantabile slot number to it and then saving that preset slot number in the Song file. It can then recall it on song or song state load.

The second choice that Cantabile could make would be “Entire Plugin Snapshots” and is what Cantabile chooses when there is no preset manager on the plugin or when the preset manager of the plugin is not compliant with VST2 standard. This choice saves all the parameters of the plugin patch along with an assigned slot number to the Song file as what is called a snapshot. The plugin’s slot presets can be added to with more snapshots which are also saved to the song file. Note that this doesn’t translate to other songs in the song list that you might load the same plugin to, each time you load the plugin in a new song you start from scratch as far as the presets go and is also why racks come in handy if you want that.

There is also the “Parameter Sets” option for the plugin’s preset management. This much like the previous option but lite weight. It also stores all the select parameters to the Song file along with a Cantabile preset number.

So at Song level the plugin always finds the plugin’s preset by drawing the information from the Cantabile Song file in one way or another.

At rack level things get more interesting because if you use the State Behaviors check boxes so you can save the preset parameters and preset numbers from the plugin’s slot in rack states. It is much like in the Song based explanations above but the data can be stored in the rack file and/or to the Song file using the State Behaviors check boxes in the rack and for the rack at song level. In addition since it is a rack the rack state acts as a snapshot much like a preset slot snapshot so the plugin parameters are stores in the rack file for the states as well.

So to summarize when using racks the plugin inside the rack’s presets are saved either in the rack file or the song file or both depending on the state behaviors switch settings in the rack and for the rack at song level.

That said and having thought about a while i settled on 3 main ways to store and recall my presets.

My first method was to put the plugin in the rack, check all the state behaviors boxes specific to the plugin and save my patches in rack states. I then selected the rack state at song level I wanted for the song. I really chose it to get faster switching on the B5 organ but used it on other plugs too.

The second method I use is to put the plugin in the rack and create a number of snapshots in the preset slots for the plugin. I then set the state behaviors for the preset to ‘controlled by parent song’ so the song can call the correct one up that it needs.

The third method is something I have been doing lately. Instead of preset labeling and saving in the rack states or the plugin snapshot slots I have no rack states, the plugin is set to “Entire Plugin Snapshots” and stays at Plugin Snapshot 1. I then set all the plugin’s specific state behaviors boxes to be controlled by the parent Song and they get saved in the song file way.

SnapShot 3899

This eliminated the patch labels and instead I just created the patch for the song using the plugin GUI and then saved the song and the preset parameters were saved in the song file.

On the rack I made a custom button to call the plugin GUI up to edit so I don’t even open those type of racks once they are made. I just edit at song level close the GUI and save the song.

No labels, just the sound I want for that song.

I use all 3 ways and probably a few more plugin specific ways but that is my input on the discussion.




I’ll throw in my 0.02 EUR here:

I try not to rely on the internal plugin presets as much as possible. Since I run my setup on three different machines, keeping presets (user patches…) in sync across all installations is too much hassle. My preferred way is to use state behaviors in my racks to create my “rack presets” - all my rack states are locked, so I don’t mess them up inadvertently, and I need to save my changes explicitly via “Update State” (CTRL-U) - nice and clean.

Two ways to do this:

  1. VST parameter state behavior as outlined by @dave_dore above - use the “entire plugin snapshots” preset model, create a snapshot called “— do not change —” and set state behavior for all relevant parameters that make the “preset” for me. Unlike Dave, I tick the right “state behavior” box and use rack states to save the plugin state. This works great for all plugins that expose all (relevant) parameters as VST parameters. Some don’t, and for those I use…

  2. “Entire Bank” state behavior: this stores a full memory “blobs” for every rack state; recalling a rack state means loading the complete plugin memory. This can cause clicks and glitches, so I try to use the first one as much as possible, especially when I need to change the rack state over the course of the song. Typical example is FabFilter Pro-Q: when I change presets via “Entire Bank” during the song, I get some clicky artefacts, that’s why I use state behaviors for all Pro-Q parameters - no more clicking.

The good thing about both modes of operation: all preset data is contained within my Cantabile rack files and syncs easily across my installations via Dropbox. Makes my life easier…,




Thank you very much, Dave. You wrote: ‘On the rack I made a custom button to call the plugin GUI up’ - how did you do that?

Hi Christoph,

Here’s how I go about it. Assuming the instrument rack is made I customize the button emoticon by right clicking and using (Windows + .) to bring up the emoticon menus.

Then I open the rack and go to rack bindings and add this binding with the target being whatever plugin you have in the rack I want to see the GUI of. I have Cheeze Machine Pro in my example so my binding target is to it.


Hope this helps :slight_smile: