I’ve looked through the forum and don’t see a good answer or suggestion, so I’ll ask. There was some mention of using Linked Racks.
The one and only Background Rack is loaded and referenced by Cantabile per instance of Cantabile. I’m sending MIDI program changes to Cantabile and adding bindings in the Background rack to load a song in the set list based on the MIDI program change value. For instance, send MIDI Program Change 12 to background rack which then loads Song 9 in the Set List. Right now, the entire night’s sets (3) are actually one set in Cantabile, so one background rack works. However, if the laptop load increases, I might have to break up the sets. Or, what if I wanted to have multiple sets with different orders and/or songs?
Yes, sending Midi Program change #1 could always load Song #1 in different set lists, but I’m also using the background rack to send CCs to multiple outboard midi gear (X32 and Kemper) which are song-specific commands. In my mind’s eye, I’m looking to load a different Background Rack for every set, but I don’t know how to duplicate that.
So how does one duplicate the overarching bindings of the Background rack on a set by set basis?
From reading the post it sounds like the bindings are the thing that may need to be broken into sets. To do it with one background rack I would try using binding groups that you could enable and disable depending on the set you were doing. You could also use background rack states to make it easier to switch. If you want more detail, let me know but I think this approach would work.
I don’t think you need separate Background Racks for each set, if i’m understanding what you want to do. The issue is song numbers, which don’t have to correspond to where they are in the set. Just assign a unique number to each song you play (and never renumber the songs in the set ! )… So song 9 is always song 9 no matter which set it’s in, and Program change 12 will always bring up the same song (assuming it’s in the current set).
I’d suggest to re-think the approach and separate your “input” and “output” MIDI streams:
use program changes coming into Cantabile to select a song in the currently loaded set list
use song-specific bindings (Song->OnLoad) inside your song files to send your song-specific commands (CCs, program changes) to your outboard devices. That way, no matter how you get to loading this song, your outboard gear will always get the right commands.
Now you can make an independent choice on how you want to select your songs via MIDI program changes, without having to worry about messing up the CCs sent to your outboard gear. So to be clear: everything directly song-related should be inside the song file, not in the background rack!
For the program changes coming into Cantabile, setlists allow you to customize the received MIDI program change for every setlist entry, no matter what sequence they are in. Now you have two basic options:
If you want program changes to step through your setlist entries in sequence, use an “indexed” binding in your background rack like this:
(I am assuming your main keyboard is sending the PCs)
This will load the first song in your setlist on PC1, the second on PC2, …
Alternatively, you can use the “by program” style: instead of the position of a song in your set list, this will use the program number stored with the song in your set list (Edit Song):
This way, you jump directly to a song using its specific program, so that e.g. “Song 3” always has PC 17, no matter where it sits in your set list.
So you could have two standard bindings to jump to your previous and next song using CCs, and a separate one using PCs to jump directly to a song by its number:
So you’d normally step through your set list in sequence, but be able to jump to a specific song by its program number - e.g. “Happy Birthday” is always PC 99.
If you use this approach, it makes sense to have one “master set list” set up that contains all your songs (alphabetically sorted) and gives them unique program numbers across your whole repertoire. If you run into capacity issues, make this setlist non-preloaded. Now when you create a gig-specific set list, you simply make a copy of that set list, remove everything that you don’t play at the gig, and drag the songs into the order that you want for that night. Now set that new setlist to “pre-load” and you’re ready to gig with this list.
And having all your outbound MIDI commands inside the songs makes sure that you don’t have to worry about matching inbound program changes to outbound CCs.
This is the way to go. You can take this a step further by abstracting your hardware gear’s program numbers using a linked rack and rack states. I.e.:
One linked rack per hardware device
One rack state per program / patch of your outboard gear
Use bindings and state behavior (within the rack) to send the midi pc messages when that rack state is selected
Put the linked racks in each of your songs and select the program you want to load whenever that song is loaded.
If you don’t select a rack state, Cantabile won’t send any PC messages at all (which is convenient sometimes)
If you enable the state behavior for “selected rack state”, you can even cycle through multiple programs within a single song by selecting different programs for your song states! This great for more complex multi-part songs or medleys.
It takes some time to build the rack and it produces a huge rack file but once you’ve put in the work, you will never have to think about MIDI program numbers again.
FWIW in addition to the comprehensive replies already given above, I wanted a background rack per set, and then realised I could do that by having a linked rack per set. Just drop it in each song and it is available across all songs.
So I do not use the background rack at all, and it works a treat
I’ll start digesting these very helpful answers. It sounds like I have to rethink my workflow with the background rack; these are all good suggestions. Making song-specific binding to send out the midi messages to outboard gear seems like a no-brainer.
I’m slowly coming to grips with set control (So far it seems to be what Torsten suggested). My plans so far:
Use Background rack to convert Program Change (PC) to Program Number.
Step on Art X-11 Foot Pedal (all it does is send a PC change corresponding to pedal sequence from 1-128) to send a “2” and Cantabile loads the song with a “2” Program Number.
Changing Program Numbers in Cantabile of set list is easy with the Edit function.
Each Song will have a binding, if needed, to send midi signals to the outboard gear "On Load" In this example, sending on Channel 2 a PC of 17 loads a “Snippet” on the X32 Mixer that is stored in slot 17 of the X32 “Snippet” library. None of these outboard gear midi sends are in the background rack.
Similar “On Load” midi function for the Kemper. On Load, send a CC or PC to the Kemper. But, the Kemper is more complicated because there can be multiple Sounds for a Song (States, in the Cantabile world).
So “Song A” is loaded by sending a PC3 into Cantabile in the above example. Cantabile sends a midi message to the Kemper to load the first Kemper sound for “Song A.” That is simple: “On Load” of “Song A,” send a PC to the Kemper. If the song has a single Kemper sound, then all is well.
What I can’t figure out is how to make the Kemper change to another preset sound without having to change the Cantabile Song/State. The only tool I have at the moment is sending another PC command from the X-11. Maybe I have to have a Cantabile Song or State for every Kemper Sound to send the PC to the Kemper. IDK. Still thinking…
Thanks for this! I’m gonna try Torsten’s Idea.
Right now, I’m having trouble with the VST3 ver 1.4.10 of TH-U accepting program changes.
It works fine on VST2 ver 1.4.7. Control changes with bindings set work fine!
I’ve been using TH-U for several years. I have the updated version, but haven’t installed it yet. The same with several other plugs. I’ve been swamped for several weeks, but if I get a chance to check out the VST3 you speak of, I will report back to you.
Yes, I use TH-U, but I use the VST2 version, and I only use program changes to switch scenes, not patches. But that’s a different story…
I just did a side-by-side test with TH-U (version 1.4.9) VST3 and VST2, and it looks like the VST3 version doesn’t react to program changes.
I believe this is a fundamental issue with VST3 plugins - as I understand, the VST3 standard has a completely different mechanism for program changes and doesn’t simply forward the PC commands to a plugin.
For the moment, probably best to stick with the VST2 version.
Thanks for that update, Torsten. That’s interesting that VST3 disregards ProgChng’s. You’d think they would make things backward compatible… or maybe it’s the new MIDI 2.0 were dealing with???
I’ve tried this in a few DAWs (Mixbus32, Cubase 12) and the VST3 problem still prevails.
Nothing to do with MIDI 2.0 - that’s a completely different animal.
The issue with VST3 is that Steinberg have completely changed the way plugins get supplied with control data - it’s not simply the MIDI stream that gets directly routed to and from the plugin. In VST3, plugin consume “events” that get sent from the host - stuff like note events, or “parameter” events. A control change or program change MIDI command needs to be translated by the host (i.e. Cantabile) to such a “parameter” event to be processed by the plugin. Not all 127 CC commands are actually available in the VST specification, only a subset.
So both sides (Cantabile and plugin) have some translating to do when dealing with MIDI CC and PC, and it depends on what both sides have done to actually achieve that translation.
Maybe @brad can clarify which MIDI commands Cantabile currently translates and sends to VST3 as events?
Overall, the idea of VST3 is to move away from classic CC and rather use parameters only, with the host translating between MIDI input and events sent to the plugin. According to Steinberg, all automation is supposed to use plugin parameters, so automating parameters via direct MIDI assignment within the plugin is against the fundamental architecture of VST3.
I guess Overloud is still somewhere on that transition and the current version of TH-U is essentially still a VST2 plugin in a VST3 shell, with the MIDI functionality somewhat messed up…
Here some info on the VST3 standard relating to this:
Q: How receive MIDI Controllers from the host?
MIDI controllers are not transmitted directly to a VST component. MIDI as hardware protocol has restrictions that can be avoided in software. Controller data in particular come along with unclear and often ignored semantics. On top of this they can interfere with regular parameter automation and the host is unaware of what happens in the plug-in when passing MIDI controllers directly.
So any functionality that is to be controlled by MIDI controllers must be exported as regular parameter. The host will transform incoming MIDI controller data using this interface and transmit them as normal parameter change. This allows the host to automate them in the same way as other parameters.
To inform the host about this MIDICCs to plug-in parameters mapping, the plug-in should implement the IMidiMapping interface.
If the mapping has changed, the plug-in should call IComponentHandler::restartComponent (kMidiCCAssignmentChanged) to inform the host about this change.
This MIDI mapping is implemented in Cantabile for VST 3, but for some plugins some events don’t seem to work - it seems to revolve mostly around program change events, which is of course further complicated by VST3’s weird preset management system.
Overall I really don’t like VST3 - it’s way too confusing and not surprising that every host and plugin has a different understand of how it’s supposed to work.
I’ll look into TH-U and will see if I can figure out what’s going on.
I’ve looked at TH-U’s VST 3 implementation and it’s returning “Not Implemented” for one of the API’s that I thought was required in order for a plugin to receive MIDI program changes.
I’ve posted a question to the VST 3 SDK discussion forum seeking clarification.
I do not believe there are Conditional Bindings for MIDI Program Changes. My thoughts were if a PC was received that was not bound in the Background Rack (Cantabile would stay in the current song), the currently loaded song could have a binding to conditionally act on the PC, such as load a different state or send a midi communique to an outside device. The currently loaded song would be the “Base Song Program Number” and if “PC = Base Song Program Number +1, do X”. If “PC = Base Song Program Number +2, do Y.” Once the Background Rack loads a new song from a PC, a new set of song bindings takes over that are relative to the new Base Song Program Number.
Seems complicated…
But the simplest path for me is to load a new Cantabile Song with every received Program Change.
In this example, sending on Channel 2 a PC of 17 loads a “Snippet” on the X32 Mixer that is stored in slot 17 of the X32 “Snippet” library. None of these outboard gear midi sends are in the background rack.