Ableton Live issues

When WA Productions Instacomposer came out, there was some debate about how it might be used with Ableton Live as a DAW. It was stated to be due to the issue that Ableton didn’t recognise MIDI channel information within tracks and hence a VST with multi-channel output could not be hosted directly within Live, as there was no way to route the separate channels to different recipient tracks.
This is correct.

Various solutions were touted to fix this (including a novel one of separating the channels by octave settings in Instacomposer ad then using a Live MIDI rack to transpose and route the data), but one prominent proposal was host it externally in Blue Cat Audio’s Patchwork to effect this, which costs money.

In a way, Live got (as they used to say in the old black and white gangster films) a bit of a “bum rap”. The fact is that Live does recognise channel data in inbound MIDI at a single port, just not in a Live track. Thus Instacomposer (and other multi MIDI channel applications) can be accommodated by the use of free VST hosts, without expenditure. The external host does not have to unpick the channel data, just fire it at a MIDI port and Live will do the rest.

For example, the free Nanohost from Tone2 serves perfectly well, as do (one assumes, not tested) other free hosting alternatives. (As mentioned elsewhere in these pages, Nanohost does not appear to support VST3s, but the VST2 version of Insta works just as well).

Hence, it’s actually straightforward to make use of both the multi-channel output of Scaler in the ‘Divisi’ progression sets, or to send the output from several synchronised Scalers to a single channel to be split up in this way. (Here is the setup for playing ‘Mars’ from the Divisi set.)

Similarly, there is no problem in Live with routing MIDI on the basis of MIDI note number or velocity using a midi effect rack. This means you can create ‘divisi’ type splits from a Scaler hosted within Live. You can also do ‘one to many’ type of routings.

So the question is when (and why) do you need a source to be externally hosted, rather than using it natively in Live? And if it is external, why Cantabile rather than Blue Cat or Nano ?

  • The main reason is the necessity that multi-channel output is not recognised for a VST hosted on a Live track, where routing is required based on channel number. (This qualification is important, as if routing can be done via note number of velocity, then it can be done by Live.)
  • Where routing logic is required which cannot be performed in a midi rack, but can in some external host.
  • (A ‘why’ reason) If it’s deemed more effective to perform some development in some external environment.

This author is of the view that situations exist where it is far more efficient to work on early stage development/ experimentation in Cantabile than it is in Live.

Notwithstanding this, if a VST has multi-channel output where the note or velocity values are not the sole determinant of the routing (and hence voice allocation) then an external host is mandated and Cantabile is a good choice.