by Opus Locus

Logic environment cable limits and disappearing MIDI events

When you are building large environments, you may discover that events are mysteriously just “disappearing” past a certain point in the processing chain. While you should first check you haven’t accidentally filtered the events out somehow, you may be running up against Logic’s undocumented “cable limit” problem.

The crucial point to understand is that the cable limit is a running count of the number of cables travelled down by any event, not the number of cables actually present in an environment.

An event can travel down 298 cables, then it will disappear. Any copies of the event made along the way, whether transformed to a different event or not, including other events generated as the result of a bang, each add their own cable count to the running total. For example, banging an audio object then distributing the result to multiple destinations by parallel cabling is a sure way to hit the limit fast — the more activated (old-style) EQs and sends, the worse it gets.

The specific arrangement of the cables (serial, parallel, combinations) is largely irrelevant, it’s the number of cables the event actually passes through that is important. Event paths that loop back and pass down the same cable(s) twice are counted twice. Taking two identical outputs from an object (parallel cabling) means the event passes thru both subsequent cable paths, and is counted as such. Cables inside Macros are counted.

It can be a real bugger to diagnose, as putting extra monitors in just makes it worse.

Strategies to avoid the cable limit problem

Remove excess monitors, cabled ornaments, “do nothing” transformers and any other “neutral” objects in the cable path wherever possible.

One-to-many junctions of any kind other than channel splitters are potentially trouble. Avoid using multiple cable outputs from objects if the object will send all its output down all cables — ie a simple “apply operation” transformer with two cable outputs is bad, condition splitter transformers are better.

Attempt to filter all unnecessary events from a cable path by using the most restrictive transformer conditions possible. Use the filter=other parameter on faders to restrict what can pass through to just the event needed.

If your data is channelised to address multiple channelised destinations, use channel splitters to keep the event paths to the destinations separate where possible.

If your data is notes, or can be transformed to notes and back (but watch out for note-off issues), the mapped instrument can be useful in that each note can be sent to a separate cable output.

If you need to distribute one event to 16 different paths, rather than multiplying the event 16 times via parallel cabling, try starting with a sysex fader containing 16 copies of the event on 16 different channels. Cable to a channel splitter, bang or trigger the sysex fader. Then re-channelise if needed with a single transformer for each channel splitter output.

If you need to make a copy of an event (whether by parallel cabling, transformed, or the same event), do it as close to the destination as possible.

The most frequent problem is trying to send events to one of many possible destinations, but being unable to channelise the data for one reason or another — if you have a parallel cable path to all the destinations the event will pass down all cables, yet only be applicable to one destination, and will presumably be ignored, or worse, passed-through, by the other destinations.

In that situation the most robust solution I’ve found is to construct a packet-based routing scheme where each event (or event group) gets preceded by a “destination” header message (I tend to use a ppress message) that switches a cable-switcher to the correct destination, ensuring no event goes to a destination where it will just be ignored. Endeavour to generate the header message as close to the cable-switcher as possible to minimise the number of cable paths that travels down.

For example, with just a few extra objects, you can build an “event number router” or “event value router” that is functionally equivalent to a channel splitter.

You can also use a multi-cable-switcher structure in MSB/LSB fashion to address up to 126 x 126 objects, using the event number of the header message for MSB and event value for LSB. If you need more than 126 x 126 destinations, the header channel number and a 3-level cable-switcher structure can be used for 16 x 126 x 126 (overkill?). I have made an example environment which demonstrates simple 0-127 routing and MSB/LSB addressing schemes — event_routers.lso.sit.

Using the above technique, you can also perform quite sophisicated processing on any existing header message to reroute streams of data on the fly, without needing to mess with the actual data type, channel, event number or value in any way. I tend to use this all the time rather than channel splitters or mapped instruments.

Finally, another really dumb (or fiendishly clever, depending on your viewpoint) workaround is to break the processing chain with an instrument object that sends the events out of Logic to a virtual or physical loopback (OMS IAC, Midi Patchbay, MidiPipe, Midi OX, Midi Yoke, Hubi’s loopback, or even a simple hardware midi out port cabled to midi in port, etc). The events come back into the Physical Input, then you can selectively pick up those events and pass them directly to the rest of processing chain where you left off — the count starts again.

John Pitcairn, Opus Locus — ©2002-2009. All rights reserved. Unathorized reproduction prohibited. This page is built using fairly simple, validated XHTML 1.0 and CSS 2. Best viewed on a standards-compliant browser (Safari, Firefox, Camino, etc). If your browser screws it up (cough, MS Internet Explorer), perhaps you should be bitching at your browser manufacturer about better support for web standards…