One problematic area of Cantabile 2 that I haven’t addressed properly in Cantabile 3 yet is the way songs are managed. I did make an attempt at it with some improvements to the set list but I’ve since realized this is a bigger problem and needs a better solution.

This post describes what I understand to be the main problems and my thoughts on the best way to resolve them.

This post is now a little out of date. Please read this follow up post where I clarify and change some of what’s described here

This is a long post because I wanted to layout as clearly as possibly what I’m planning in this area. Please bear with me…

The Problem

The main problem with the way songs are managed in Cantabile 2 stems from the fact that a song’s definition is spread across the set list, session states and the session. A song isn’t defined in one place as a stand alone entity.

The way it’s typically done in Cantabile 2 is to have one large session file holding all the plugins you need, sub-sessions defined for all the different song parts and the set list is used to define the order of those sub-sessions.

I call this the “monster session” approach and it has a couple of problems:

  1. Managing the session file becomes tedious because every song and song part often requires a sub-session — sometimes just to select a different tempo or time signature.
  2. Managing the set list is tedious because you can’t manage the song and all its parts as a single entity.
  3. Plugins that aren’t required by a song need to be manually bypassed or put into sleep mode, often requiring visiting many session states.

In the Cantabile 3 preview I’ve improved this slightly by giving each song a sequence of song parts and a song-level transpose setting. Still, it only helps a little and the definition of a song is still spread across the set list and the session file.

While the monster session approeach is pretty flexible and provides fast session switching, it becomes more and more difficult to maintain as the number of songs grows.

Introducing Song Files

My first thought on how to solve this was to introduce a new song file that holds just the information that the set list holds — the session file to use, a list of states to progress through and a transpose setting. However it soon became obvious that just about anything to do with a session file could also be song specific including time signature, tempo, media files, even plugin instances.

The solution I’m considering is to make song files session files. In fact I’m probably going to rename “sessions” to “songs”. That’s right — I’m thinking that session files are going to be called songs from now on and you’ll have one file per song.

Session states (aka Sub-sessions) will now be called just “states” but within a song file they’ll be used to manage song parts. This allows each part to have a different set of plugins, time signature, tempo etc…

Everything about the song will be defined in this one song file — its parts, the sounds and effects it uses, media files, transpose settings, tempo, time signature and in the future probably a set of documents and notes (for a document/score viewer).

Simplyfing the Set List

Once a song is completely defined by a song file, the set list can be cleaned up. Each entry in the set list no longer needs to specify which sub-session to use and for the current v3 previews the list of song parts and the song-level transpose setting can be removed.

Each entry in the set list becomes just the name of the song file to use. Re-ordering a set list just means re-ordering the songs. To create a new set list you just need to pick the song files you want and away you go.

Introducing Rack Files

What I’ve just described solves the set list/song management problem but creates a new problem — if each song needs to define its own set of plugins it becomes difficult to manage any sounds that need to be re-used across multiple songs. Worse, switching between songs will be slow as plugins for each song are reloaded.

In other words, the main benefits of the monster session approach will have been lost.

This is where Rack Files come into play.

Forget everything you know about racks in Cantabile 2. Cantabile 3’s rack files are a new concept — both in the way they work and the way they’re used.

A Cantabile 3 Rack is essentially a session that can be linked into parent session. ie:

  • Songs are parent session files,
  • Racks are child session files.

The idea is to define the sounds and effects in racks and then reference those racks from songs.

Although the purpose of racks and songs are very different, they’re essentially the same except for a few minor differences:

  • Racks can define an additional set of input ports that the parent can route to.
  • Racks don’t have tempo and time-signature settings — these are always controlled by the song.
  • Racks can’t be opened as a top-level file in Cantabile — they’re always loaded as part of a song.
  • Rack and Song files will be given different file extensions to separate their intended usage (although they will have the same file format)
  • Rack and Song files will probably be saved to a different folders to keep them separate.

Racks will appear in the user interface of a song just like a plugin slot. They will have states (sub-sessions) just like sessions currently do and these will be selectable from the rack slot just like how you select a plugin preset.

Editing of both racks and songs will look just like editing a session now. When a rack is opened for editing the main window will switch from editing the song to editing the child rack with a back button to return to the parent song file.

Racks can route to other racks and multiple racks can be routed to a rack. eg: multiple synth racks routed to a master effect rack. This implies that if two or more parent racks refer to the same child rack they all use the same instance.

You won’t have to create routes from the parent file to a rack’s input ports if you don’t want to. That is, racks can contain their own routes from global inputs. eg: a synth rack might contain it’s own internal routes from “Main Keyboard” to the synth plugin. Just loading such a rack into a song file would be enough to make it work.

Although Racks can have input ports they don’t have output ports. A parent can’t specify where the output of a child rack goes — this is always defined by the rack itself. You could however setup states within the rack to control its output routing and use those states to control the routing from a parent.

Song Switching

The above describes how rack files can be used to share re-usable sounds across multiple songs. Less obvious is the impact this has on song switching.

If two songs both use the same rack, when switching between those songs the common racks don’t need to be reloaded. Input routes from the parent song might need to be updated and perhaps the rack’s state will be switched, but otherwise the rack continues to run as if nothing happened.

There are some very clear advantages to this:

  1. Every rack used by every song in the entire set list can be pre-loaded so nothing needs to be loaded during performance and song switching will remain fast. This is effectively rebuilding the monster rack dynamically from a series of smaller, easier to manage components.
  2. Cantabile can be smarter about keeping unused background racks sounding out until they go silent — to prevent sounds getting cut off when switching between songs.
  3. You don’t need to manage a complex set of states in your session files. Cantabile will know which racks aren’t used by the current song and can automatically stop processing them when they’re not in use (but keep them loaded so they’re ready at an instant’s notice).
  4. You shouldn’t need so many states to organise your songs.

What do you Think?

This is a pretty radical change from the way things are currently done and you might need to read through it a couple of times to get what I’m talking about. Let me know if there’s anything that needs to be clarified or better explained.

I’ve come up with this approach based on lots of great feedback from many users over many years. It’s probably doesn’t solve the exact needs of every user but I hope it will solve the main pain points for the way most people use it.

To get this working will require fair amount of effort — in fact there are some nasty details which I’m not sure how to resolve yet. I’ve written this up now because I want to make sure I’m going down the right path before committing to it.

It’s also important to get this right before version 3 is officially released. While Cantabile 3 is still in preview I have the a bit more liberty to change (and break) things.

Please let me know what you think.

Please read this follow up post