A MIDI master sequencer keeps its slave devices synchronized by sending clock messages, 24 times per beat. The slave can use this to measure the current tempo, and might respond by playing some note, or by updating an internal timer used to drive arpeggiators or LFOs. If it is a sequence-oriented device, like a groovebox/drum machine, it will also use these clock messages to update its song pointer – the bar and beat it is currently playing.

The system works reasonably well, but it has one significant flaw: there is no provision for resynchronizing song pointers, and so the clock tends to drift over time. If an error occurs somewhere along the chain, and a clock message gets lost, all downstream devices remain out of alignment until the performance stops and starts again.

In general this is not a big problem. Errors are rare, and are not likely to cause perceptible drift in a 5-minute song. For people doing soundtracks, there’s a separate timecode system that provides absolute position. Further, many people do all their sequencing in software now, which solves the drift problem (and introduces many others, of course!).

My performance style, unfortunately, happens to live right in the sweet spot for this problem. My setup includes four tempo-synced devices, and I play continuously for 60-90 minutes, in a “thru-mixed” style which leaves few natural breaks where I could stop and restart the clock without creating an audible glitch. As a result, I run into synchronization problems in almost every performance. Sometimes I can work it out, but sometimes I just grind myself into a trainwreck.

Flush with success from my rhythm robot project, I’m thinking of building a custom MIDI clock device that will solve this problem for me. I imagine a straightforward black box with a big tempo knob, play/pause and stop buttons, a tap tempo button, and a “synchronize” button. Big LED readouts would advertise the current tempo and bar/beat song pointer. The back panel would have three or four parallel MIDI outs so I could run multiple slave chains, reducing latency.

But how to implement the synchronize button? MIDI does include a “set song pointer” message, but a sequencer is not supposed to send it while a performance is running – you’re supposed to pause first, set the position, then continue. Otherwise, maybe the slave device wouldn’t update itself quickly enough, and it’d miss a clock message! Oh no! … but how, exactly, is this any worse than staying out of sync? And this may have made sense thirty years ago, but I would be surprised if any of my modern gear has any trouble swallowing an extra message every now and then. Perhaps they ignore it, though; in that case, I’ll try sending a very quick pause/position/continue triplet. And if even THAT doesn’t work without causing a glitch, I’ll fall back on the fact that everything I do is aligned to groups of 4/8 bars, and the “synchronize” button will simply wait til the next 8-bar break, then send a “start” message, rolling everyone back to the beginning of the loop.

It should be pretty easy to test this out before I actually build the box. I’ll just rig up an arduino, a midi-out port, and a push button, and have it send clocks at some fixed rate, then see what happens when I send a song-position message.