Seeking Feedback on Preset Model feature


Hey All,

What does everyone think about the new Preset Model feature?

I’m a little concerned it’s over-complicating things but at the same time I think it solves some real problems - or at least simplifies some use cases. For more background/discussion on it, see here.

So far the feedback has been mostly positive but I’m keen to hear what everyone thinks. If you’ve got a few minutes to play around with it, please do so and post any suggestions for how to improve it, make it easier to understand, questions about it, thoughts on whether keep it or ditch it etc…

I’m going to be mostly unavailable for the latter half of this week so I’ll put off making the decision until early next week. I need to make a decision though so that I can start to move forward on some other things while continuing to stabilize the VST 3 support.



I absolutely love this feature - can’t wait for it to become stable enough so I can re-work my live racks. It makes life so much easier around those plugins that have their own funky preset management intermingled with VST presets. Currently, I need to do a whole lot of “entire bank” state behavior juggling with VB3-II, Blue-II (Rob Papen), Korg M1, OP-X etc. They all have their funny implementations of VST presets that make them highly unpredictable trying to use the original preset mechanism.

Plus the “light” preset mode (exposed parameters only) is super-helpful avoiding some of the “entire bank” issues e.g. with FabFilter plugins that tend to generate audio glitches / crackles when loading an entire bank.

So don’t even think about ditching this! :scream:




I’m with Torsten for this, It’s make things more understandable and easy to use.

Is anybody intersted by adding a bank feature ? this way we can have all the banks/presets accessible at one level ! maybe add a tag functionality ?


I’d second @Torsten’s feedback - it’s a really great feature, although I have to admit, the number of big gigs I have at the moment has prevented me from upgrading beyond build 3615, so I haven’t actually played with it in anger.

I’m not sure it adds complexity - I would say it stops the complexity from being hidden, which is a good thing. Cantabile can do so much that it can sometimes seem like magic behind the scenes, and that sometimes doesn’t align what the user’s mental model. Putting some of these plugin behaviour choices into the user’s hands must be a good thing.

Just looking forward to this stuff being in a stable build.



Haven’t really tried it myself due to the need to do a complete set list rebuild (which i am doing on the stable build!), but have been following the conversation and it all seems to make sense and if plugins have different implementations of presets, then something like this should help make managing this area better.


Hmm, do you mean having multiple banks of Cantabile presets for a rack / plugin?

Count me in! I haven’t gotten to the point where I’ve exhausted the 128 preset limit, but it’s only a matter of time. And it would definitely be a nuisance having to create multiple instances of a rack just to have more presets…


Banks would be interesting for cataloging sounds.

Something I’d like to see is for the Internal presets (formerly known as pseudo-presets) to have a manual save and a cancel option. Many time I’ve created “the sound” then accidentally move something or advanced the plugin patch thereby destroying my latest creation.


Absolutely +1 on that one (of course for both types, plugin snapshot AND parameter snapshot) ! No need to imitate the uncomfortable and error-prone VST paradigm with these Cantabile presets!


Regarding banked programs, that’s fairly easy to implement since 128 is a arbitrary number I picked to match the MIDI program change event range. There’s nothing hard coded in there that would prevent this growing to what ever. Perhaps I could add an option into the dialog where you change preset models where you can set how many banks you want and that would just increase the number of programs available in the list. That should work in combination with a bank program change binding to give more than 128 slots.

So kind of like States where you can lock them and then manually update them?



That woul work splendidly. Anything to keep me from fat-fingering the work away.


Yes,exactly like you describe on both would be great.


OK. I’m about to go radio silent till next week, but then I’ll look at finishing this off.



Now that I’ve got some touring out of the way, I’m contemplating upgrading to the latest experimental build and having a proper play with the new Preset Model feature. But one concern I have is how existing plugin instances will be affected. I use a variety of different ways of driving plugins, which broadly fall into the 3 model categories but done the “old way”, i.e. built-in preset selections, the “Entire Bank” way, and explicit state behaviour set on parameters. I’m wondering about the best way to migrate to the new model.

My guess is that currently my preset data is bound up on state behaviour (either “all bank” or parameters), and so the migration would be something like:

  1. Upgrade Cantabile
  2. For each plugin in racks, select the most appropriate preset model
  3. Go through each rack state, selecting a new preset each time and saving
  4. When all the patches are done, switch off the old state behaviour check boxes

It feels a bit precarious - if I change preset at the wrong time, could I overwrite my state behaviour data, and lose my sounds?

A useful feature would be a “Convert rack state into presets” command on a plugin instance that automates this, going through each rack state and transferring the stored state behaviour into the new preset model, giving you one preset per rack state, perhaps named after the rack state, with the new presets automatically selected for each rack state, and state behaviour settings changed accordingly…



Might be a good thing if we follow up on this:


That seems like a good idea. To be honest right now I’m just trying to confirm the preset model options is a good feature to keep - seems most people like it. Let me think about how an enhancement like this might work.