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:
-
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…
-
“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…,
Cheers,
Torsten