Pseudo Preset Madness

I have been dealing with a strange issue related to pseudo presets for quite a while. At this point, I am not sure if it is a bug, or something with my configuration. It’s a little complicated to explain, but here goes:

In a nutshell, pseudo presets for plugins in racks are not being preserved consistently. My general way of working is that I place a single VSTi in a rack for reuse between songs. Most racks have nothing but that one VSTi, but some have an effect plugin placed after it. I use Omnisphere 2 a lot, so I have three racks, called ‘Omnisphere’, ‘Omnisphere 2’, and ‘Omnisphere 3’. Most other VSTi’s have a single rack named for that plugin. There are two issues that I run into:
1- The available Pseudo Presets for a given rack will be different in different songs. For example, I can open the ‘Omnisphere’ rack in song A and the Omni instance in it will show 50 presets. I can then open the ‘Omnisphere’ rack in song B and the Omni instance in it will show 49 presets, where the first 48 are identical to song A, and the 49th preset is different (and the 50th is missing).
2- More common, and much more of an issue - The preset I have chosen in a song doesn’t always stick. For example, let’s say I have a set list with songs A and B. Both songs have the Omnisphere rack in them. In song A, I open the rack, and choose Preset A. I then open song B and choose preset B in the Omnisphere rack. I ‘Save All’, and exit Cantabile. When I reopen Cantabile, open the setlist, and load song A, the Omnisphere instance in the rack has preset B loaded.

In reality, simple examples like this always work fine, but once I start working with larger set lists, eventually problems develop. I am working in a set list now that has 20 songs. Every time I load the set list, many of my rack presets are incorrect. If I fix them all, they stay correct for that session, but as soon as I close Cantabile and reopen, incorrect presets show up again. The odd thing is that the errors could be in any rack, in any song - it isn’t consistent from session to session, so I need to literally check every single preset every time I load, which takes forever.

I have tried every combination of the ‘Selected Program’ and ‘Entire Bank’ state behaviors, including having neither of them checked for the rack or song column. Nothing seems to work. I have settled on having ‘Selected Program’ checked in the song column, as that is the behavior I think I want. I never use rack states, just the presets, which should be controlled by the song.

Two things I have noticed that seem odd. First, the .cantabileSong files have a ‘bankData’ entry for plugins in racks. This entry contains a lot of data - often several hundred KB. Why is this there if I do not have the Entire Bank behavior checked? Second, when I choose a preset for a plugin in a rack, that rack is marked dirty. Is that intended? I haven’t changed anything about the configuration of the rack, just the loaded preset for that song. The reason this seems relevant is that I often find the last preset i loaded in a particular song gets selected in other songs after I save, then close and reopen Cantabile.

Yes. I think it’s simple: don’t use “Save All”. Use “Save”. Save All do NOT save the changes you make inside a linked rack general speaking. I ran into this a few days ago too.

Thanks for the reply, Christian. I don’t think Save All is the issue because I almost always save a song individually after editing it anyway. I just use Save All as a safety measure. Furthermore, if I have plugins and racks set up to be controlled from the parent song, I shouldn’t need to save the rack in order for changes to the song to be reflected.

Hi Tom,

Can you send me a copy of your songs/racks with instructions on how to reproduce the problem and I’ll take a look.

Email is best:


You have to do SAVE while you are inside the rack. I think it’s called “Save rack”. If you save on song level changes inside the racks might not be overtaken.


I will send you an email later today with the applicable files. I also will be sending a full list of the presets that changed after closing and reopening C3.

One thing that would help me (and probably others) is a clear explanation of how the ‘Selected Program Exported Behavior’ checkbox is supposed to work. Below is a description of how I think it is supposed to work, but I have seen inconsistent behavior, so I am not sure if this is correct. Both scenarios below are with the ‘Selected Program - Enable State Control’ checkbox and both ‘Entire Bank’ checkboxes unchecked:

1- ‘Selected Program Exported Behavior’ checked:

  • The rack never is responsible for the preset that gets loaded; this is handled by the parent song
  • The preset can be changed by different states in the parent song.
  • The parent song stores the preset number at objects.[index].exportedRackState.plugin.[index].selectedProgram, but does not store a full plugin state blob.

2-‘Selected Program Exported Behavior’ unchecked:

  • Identical to above, except that there is only one preset for a plugin per song - state changes are not able to change the preset.

The 2nd scenario above is the one that I ideally want, because I have found that state changes can cause a reload of plugin data even when all states in a song use the same preset. This causes a significant delay. So, for a long time, I had both ‘Selected Program’ checkboxes unchecked. It usually works the way I expect but not always. I have had situations where changing the preset for a racked plugin in one song causes the preset to change to that same value in another song. In both scenarios, I usually find that no plugin blob is stored in the song file, but occasionally, there is one.

Can you clear this up, Brad?

@Christian RE: If you save on song level changes inside the racks might not be overtaken.
If this is true, I believe that is a bug. When you save a song, it also saves any racks in that song. You can see that by the fact that the little dot after the rack name that indicates it has changed, goes away.

Many thanks,

This guide explains how States work. See if it is helpful

Please check this thread:

Thanks, RackedBrain. I have read that document, but I just glanced through it again and realized I had completely forgotten about the ‘Exported State’ behavior on racks in songs. I am not at my Cantabile PC right now, but I will check later to see if my songs have this behavior set or not. I suspect some do and some do not. That would clear up one issue, but still wouldn’t explain why some of my songs are getting their stored preset data overwritten. What appears to be happening is that when I change a pseudo preset for a racked plugin in one song, other songs change to that preset, as well. This usually does not happen, but it does occasionally.

@FantomXR - I did see that thread. At the end of the thread, Brad says he fixed that issue in the latest build. Are you still seeing it?

Build 3588 addresses a bug related to this. Let me know if problem persists.

Hi Brad,

I sent you an email yesterday, but for the sake of keeping this thread current, 3588 improves the issue, but it doesn’t completely solve it. I sent you a recipe for and a set list with three songs. One song still exhibits the problem, while the other two do not. I am not sure what is different about the one song that would make it behave differently.

I’ll get it right eventually… Please build 3589 has another fix in this area.

It looks like “eventually” has arrived. I can confirm that the bug is fixed in 3589.

Thanks, Brad!