In my previous post Fixing Song Management I outlined some thoughts on how Cantabile’s song management could be cleaned up and improved and asked for feedback.

The feedback has been extremely useful and thanks to everyone who took time to write to me — lots of good comments, ideas and suggestions. Mostly the feedback has been very positive but some valid concerns were raised and also some confusion.

Since then I’ve been busy finishing Cantabile’s recording features but song management and all the feedback has been simmering away in the back of my mind. In this post I hope to bring all those thoughts and ideas into a cohesive plan.

The Concern

By far the biggest concern raised was that existing setups would be broken. Some users obviously like the monster session approach and I didn’t make it clear enough that nothing I was planning would break what is already in place.

(In retrospect I did imply that the set list would no longer store session states which would in fact break things. What I meant however was that the set list would no longer need to store this).

To be clear: nothing I’m planning here will break what Cantabile 2 can currently do.

As per Cantabile 2, each song in the set list will have the name of the session file (now song file) and an optional initial session state to load. This maintains backwards compatibility for everything the monster session approach can do in Cantabile 2.

However, Cantabile 3’s current support for Song Parts will be dropped. The sequence of session states and the transpose setting on a song entry as well as the associated Song Part commands will all be removed.

If you want to continue using the monster session approach and you have song parts you’ll need to manage them as multiple entries in the set list.

The Confusion

Most of the confusion from the previous post stemmed from this statement:

Although Racks can have input ports they don’t have output ports.

In retrospect, I should have clarified this more. Going forward though you can ignore this statement because it doesn’t apply anymore — racks will have input and output ports.

The Hidden Complexity

In the previous post I said that racks can accept input from and send output directly to physical ports. Thinking about this more it seemed like an unncessary complication — mainly because it hides external routing within the rack — routing which is not easily visible from the top level song.

Given the decision to implement output ports on racks it’s also no longer necessary — the song file can control all connections to and from the physical hardware ports itself.

It’s a little extra effort to setup each song, but I think the improved clarity makes it worth it. Besides, it’s pretty easy to create a new song by saving an existing one with a new name and then tweak it as necessary.

The Denied Problem

Although I was vaguely aware of this when I wrote the last post, letting any rack connect to any other rack and control it’s session state presents a problem.

Suppose you have two instrument racks I1 and I2 both routed to an effect rack E. When editing either instrument rack, each can set the session state for E. Depending on which songs I1 and I2 are eventually used in, this can easily lead to a situation where it’s not entirely clear what state rack E should be in.

While I could work around all this with a technical solution, it’s not just a technical problem — it’s also a usability problem.

To solve this, only the top level song files will be able to load racks. The heirarchy becomes very flat — one top level song file with a one level deep set of racks. The selected state of every rack will be controlled by (and visible from) the song file.

The Conflicting Expectation

In the feedback it became clear there are two schools of thought on what affect editing a rack should have on the songs using it.

  • School 1 says that all songs using that rack in that state should get the changes.
  • School 2 says that only the current song should be affected.

These are completely conflicting expectations and both have merits. However school 1 is an important requirement while school 2 can be worked around with tooling and a little care.

Cantabile will be implemented as school 1 — changes to a rack will be picked up by all songs using the rack. Later I might provide tools to better support school 2, but for now you’ll just have to be careful.

Defining Racks

Taking all the above into account, this is how racks end up looking:

  • They have a set of user editable input and output audio and MIDI ports.
  • They can’t connect to the physical ports defined in Options — only their self defined ports.
  • They can’t load or route to other racks — only their self defined ports.
  • They don’t have a transpose, tempo or time signature setting.
  • They do support MIDI Assignments but only from their self defined MIDI input ports.
  • They do support Triggers — but can only send to their own MIDI output ports, or contained plugins.
  • They do support States — which can be selected either from the parent song, or while editing the rack (in which case the loaded parent song is automatically updated)
  • They do support Media Players — but can only route to… well, you get the idea.

In other words, racks become very self contained black boxes. The song controls all routing outside the box, the rack controls all routing inside the box. Racks are also completely blind to anything outside the box.

Loading the Entire Set List

In the previous post I said that Cantabile would load all racks used by the loaded set list. What I didn’t clarify is when it does this and whether there would be any control over which racks are loaded.

I’ve had a couple of ideas about this including a way to selectively pre-load racks. For simplicity sake though (at least initially) it’s going to be an all or nothing approach — there will be an option that indicates whether set lists should be fully pre-loaded or not.

When pre-loading is enabled, and a set list is loaded, all racks referenced by any song in the set list will also be loaded. Switching songs will only involve applying any required session states and activating/deactivating racks as required by the song.

When pre-loading is disabled, racks will be loaded and unloaded as required. If a rack is used in the song being unloaded and by the song being loaded, that rack will be kept loaded and re-used (probably).

Each set list will have it’s own pre-load option so different set lists can behave differently.

Other Tools

Also obvious from the feedback was the desire for two other tools:

  1. Set List Builder — a tool for quickly building a set list.
  2. Set List Verification — to way verify all plugins, media files, racks etc.. are available.

I agree with both of these ideas, but they’re outside of the scope for this initial version. Neither are absolutely necessary to get this up and running and will be left for later.

There were also some other really good suggestions but most of these I’m going to hold until I get the basic functionality working, see how it goes and then iterate/improve it.

Yes or No?

What do you think? Is there anything obvious I’ve missed? Do you agree with this approach?

Although I’m now pretty committed to this approach, I’m still keen for feedback because it’s an important but complex area that I want to get as right (well as right as possible). Please get in touch if you have something to add.

Thanks again to everyone who gave feedback on the previous post — much appreciated.