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.
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…
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?
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:
Upgrade Cantabile
For each plugin in racks, select the most appropriate preset model
Go through each rack state, selecting a new preset each time and saving
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…
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.
Hi All
I’ve been using Cantabile Performer for about 18 months and I am about to hit the limit of 128 presets for a number of plugins.
I’ve got racks which are in every song and these set the states of plugins such as compressors. Can the pseudo presets be increased from 128 by using banks of presets - two banks would be enough for me. I don’t expect my practice list to reach 256.
Hope someone can help me.
Baz
If you have more than 128 rack states, it looks like you essentially have a specific rack state for pretty much every song… In that case, using exported parameters might actually be the far better approach. That way, you set the parameters of your compressor and save them with the song, instead of with the rack. No need to use rack states anymore.
I use this all the time with delay/reverb racks: I don’t use rack states with them, but rather mark all relevant parameters as “exported”. That way, all the reverb/delay settings I make are saved with the song instead of with the rack - no need for dozens of rack states. And I can even have different settings per song state (by setting state behavior “exported parameters” to “on” for these racks).
Of course this would mean that you’d have to rework your compressor racks to this different mechanism, which can be a bit of a pain…
Hi Torsten
Many thanks for your quick reply.
Unfortunately I am using 256 plugins with about 24 of those using a preset per song. Also three of those plugins are used in eleven instrument racks and a mixer rack (using MixMaxTrix recommended by a Cantabile user Goldy).
So changing from using presets to exported states is a nightmare.
Also I don’t know where to start and which state behaviours to select.
I like using presets because if I need to edit a rack by adding a plugin, I can edit the whole rack very efficiently without changing songs by just selecting states.
Also it’s easy to copy one preset to another for a plugin and I can easily see if I’m using the correct preset for a rack state.
As you can see, I’m very happy using presets because I think I know what I’m doing.
I am just hoping that Brad can see the advantages of increasing his preset model to more than 128 slots for those of us who are not advanced users.
I get that - that would be a major overhaul for very little value.
I think expanding the preset list beyond 128 has been discussed, and @brad hasn’t ruled it out. But it doesn’t seem to be on the immediate development roadmap, so don’t hold your breath…
I’m not against increasing this and I can’t think of any limiting factor off hand. (I just chose 128 to match the limit of the MIDI program change event).
I’ll look into it next week. (ping me back to remind me if you don’t hear anything).
