Feature Request: force Pseudo-Presets

Hey all,

I’m currently struggling with the many ways that different plugins use to manage their presets.

  • VB3-II has its presets fixed into every instance - once you save a preset, it is the same for every instance - no way to have different list of presets in different racks (e.g. a dual-manual rack and a pure solo rack)
  • Rob Papen’s Blue II manages preset banks in its own folder on the disk - as long as you stay within one bank, things stay saved with the rack, but once you change into a different bank, all your changes in your current bank are lost, unless you save things to disk first.
  • Korg M1 always shows the current card or user bank to Cantabile - once you change bank or card, Cantabile’s saved states lead to completely different sounds.

These are just some current examples that make me struggle with packaging my patches - especially difficult when it comes to managing that across three machines - I need to explicitly move files across between machines in addition to my Cantabile folder.

What I would love: @brad, can you give us the option to force pseudo-presets for individual plugins? This would mean that I could use the plugin’s internal logic to navigate presets, find my sound and customize it, and Cantabile would simply use the current Pseudo-Preset mechanism to store the current state of the plugin with the rack or song when saved.

This way, all my relevant patch information would be stored in Cantabile files, and that would be the only thing needed to synchronize across all my devices.

@brad, do you think that this would be possible to realize?



1 Like

Hey Torsten,

Internally to Cantabile this is almost trivial to implement as it’s just a flag indicating if pseudo presets should be used or not, but there’s a bigger question of other impacts this might have - the main one being preset switch times. Pseudo presets can take longer to switch than native presets because the plugin is basically told to do a full bank load.

This also ties into another idea of “lightweight presets” - where Cantabile just manages the plugin’s parameters which should allow for fast (but less capable) preset switching.

How does this sound… a way to select a plugin’s Preset Model:

  • Standard
  • Pseudo
  • Lightweight

This would need to be a per-plugin-instance setting (as opposed to per-plugin setting) because it relates to the saved data for that plugin instance. Not sure what would happen when you switch the preset model - but that’s probably rare and I suppose the behaviour might not matter too much.


PS: some of this might also provide a nice work around for some of the the problems I was seeing with VST3.

This sounds great - for a bunch of plugins I simulate this “lightweight preset” mechanism by setting all the plugin’s parameters to have state behaviour, and drive it from rack state changes. Proper preset control via this mechanism would be superb!!


1 Like

Absolutely great idea! +1 from me! :slight_smile:

I’ve been think about the lightweight preset idea some more and realised that there still needs to be a way to select a “base” plugin program - ie: the plugin configuration onto which lightweight parameters are applied.

What if each lightweight preset stored:

  • a base program number (ie: one of the plugin’s built in programs) and
  • a set of parameter values.

That way lightweight presets would be more like “variations” on the plugin presets. You could switch between the various lightweight presets and the underlying program would only be swapped if you switched between lightweight presets with different base programs.

Or is that too confusing and would be better to just have one common base program that’s shared by all the lightweight presets.


TBH, I think that combination of base and values sounds a bit too complicated - especially given the convoluted preset management system of some plugins. I’m just imagining finding a sound in bank 4, patch 17 of M1, modifying it a bit and then “saving” it as lightweight preset 1. Next, I go to Cantabile preset 2, find a sound in bank 2, patch 55, modify it and expect it to be in preset 2 as I find it.

Now if Cantabile called up an M1 preset before applying a lightweight preset, it would in all probability call up a completely wrong one, since for M1, only the presets from the current bank are accessible to Cantabile.

So, if a plugin preset needs any data from an underlying preset BEYOND the exposed parameter, the “lightweight” approach is probably not the right one - I’d need to use the full Pseudo-Preset approach. Otherwise things will get super-confusing fast.

So I would engineer a “lightweight” preset approach to ignore whatever plugin preset is currently selected - if this works out for the respective plugin, that’s good, otherwise it’s advisable to use the full pseudo approach or the internal presets.Really depends on how many parameters a plugin exposes.

So a “lightweight” approach may be a bit of “use at your own risk”.



I agree, I think using a common base program sounds like a more understandable and robust approach. Even just zeros for everything. But even then, I’m not clear whether that would be sufficient to drive a plugin like M1 - the key would be whether plugins have any “internal” parameters that aren’t exposed to Cantabile as parameters.?

M1 is special in that way because it doesn’t expose almost any parameters to cantabile. Only very basic things.

I agree on this topic. Since every plugin seems to have its own preset management it’s hard to get an equal preset system through all plugins. Checking all parameters in state behavior window works most of the time. But f.e. M1 does not.

I’d love to have a method that works with all plugins … but I’m not sure if that is something brad is able to integrate.

so, essentially:

  • if a plugin exposes all or most of its parameters, a “lightweight” approach would be the equivalent of marking state behavior for all exposed parameters and using states - but wrapped into the preset paradigm
  • if a plugin doesn’t expose sufficient parameters, we’d need to use a full “pseudo” approach - equivalent to selecting “entire bank” state behavior, but wrapped into the preset paradigm




1 Like

BTW: I can work with M1, since it encapsulates the full bank logic in its plugin state. So if I define a user bank with my own specific sounds, they get saved with the plugin instance, which is nice. This way, everything transports nicely between my three setups, and I can have different instances of M1 with different preset banks.

The only thing that doesn’t work is switching between patch and multi setup - that one I need to lock down for every instance.

It’s definitely worse for VB3-II or Blue II - for these, I’m currently fiddling with exposed parameters to see how far that gets me…



1 Like

Hey Guys.

Thanks for the feedback. Still thinking about the best way to implement this. A couple of things:

  • With the lightweight presets you’ll almost certainly still want a way to load programs from plugin’s built-in program bank (assuming it has one). Some plugins provide this capability in their own GUI - some don’t, so Cantabile will still need a way to get to that list and I’m not sure what the GUI for that would look like.

  • For settings that aren’t exposed to the host as parameters, you’ll still be able to tweak these in the plugin GUI - but obviously that setting will effect all lightweight presets - not per preset.

  • Lightweight presets will definitely have caveats - in which case you’d use one of the other preset models instead.


Hi All,

I thought I’d chime in on this topic. I have the same problem with VB3 II that Torsten, and Volker (Humphrey) are with this. Humphrey said he was using the automation pseudo preset method some of us use on various plugins that are difficult, to work with VB3 II. I got looking at the issue and found that

a) using “Entire Bank” State behavior was for the most part good as a solution but occasionally would produce corrupted results in use

b) using pseudo preset automation works reliably but takes a while because you have to either start from scratch on each patch or copy and paste to the first preset to get it done.

c) using “Selected Program” State behavior works great once the rack is loaded in a song and you make an actual rack state change but … does not load the correct patch into the working buffer on Song Load (it loads the default Preset # 1 patch) even though it does load the Name and GUI knob and slider positions for the correct preset

d) I was able to fool VB3 II into loading the initial desired preset by adding some bindings to my VB3 II rack that perform a preset increment and decrement on Song Load for the VB3 II. This method is shown here


It seems to me the only issue VB3 II has is that it won’t load the correct preset to the working buffer on initial Song Load only. After it is loaded the state change behaviors all work OK. Is this something you or Guido could address? It would fix at least that method of use (‘Selected Program’ style of selection for states). I realize it won’t fix the Bank problem Torsten described but would be better anyway.



Sounds like a bug in the plugin. Best bet might be put together a video showing the problem and forward it to myself and Guido.

@brad, I uploaded a video to the dump site for you to check out.



Hey Dave,

Just looked at your video. So if I’m understanding correctly, the preset is getting loaded correctly, the GUI display is correctly, it’s just the sound that’s wrong?

In that case this has to be a plugin bug. Please let Guido know about it.


1 Like

Yes, @Torsten and I both have made other posts here in a Topic I started regarding this very VB3 II problem for morethoughts on it from others.