When most musicians first encounter MIDI synchronization, the distinction between MIDI Clock and MIDI Time Code (MTC) can seem confusing. Both are used to keep devices running in sync together, yet they approach the problem from fundamentally different perspectives.
MIDI Clock
MIDI Clock thinks in terms of music. It doesn’t care where a song begins or ends. Its job is simply to maintain a shared pulse. By transmitting timing messages tied to tempo on a regular basis, MIDI Clock allows drum machines, sequencers, arpeggiators, and effects to stay locked to the same groove. As long as every device agrees on the beat, the performance remains synchronized.
It also allows to synchronize playback thanks to Start/Stop/Continue and Song Position Pointer messages. The song position is considered as a musical position in 16th notes within the song.
MIDI Time Code (MTC)
MTC, on the other hand, strictly thinks in terms of time. Derived from SMPTE timecode used in film and broadcast production, it communicates an absolute position on a timeline.
Instead of telling devices how fast the music is moving, it tells them exactly where they are on a timeline. A system receiving MTC knows whether playback is at 00:01:30:12 or 01:15:42:08, making it possible to jump instantly to any point in a project and remain synchronized.
Which One To Choose?
Neither protocol is inherently “better” than the other because they were designed for different tasks. MIDI Clock is about maintaining a shared musical pulse, while MTC is about maintaining a shared position in time. One synchronizes beats and musical time, the other synchronizes absolute timelines. If you only need one type of synchronization at a time, the choice is easy.
However, while both MIDI Clock and MTC are widely used, neither provides a complete nor perfect synchronization solution on its own: sometimes you want to refer to a musical timeline expressed in musical beats, but none of the protocols gives you enough information to do this accurately.
First, MIDI Clock has a relatively low timing resolution, and its dependence on a shared MIDI data stream can introduce clock jitter and timing drift. The fact that the BPM is derived from the rate of incoming clock pulses does not help if you want to track the position on a timeline precisely. The Song Position Pointer message is expressed in 16th notes, which limits the precision to navigate a timeline, especially at low BPM.
On the other hand, since MTC addresses the problem from the opposite direction, it provides an accurate timeline reference but absolutely no information about tempo, beats, or musical structure, which makes it useless to synchronize bpm between devices. This is especially annoying when tempo changes over time and you need to lock to a timeline expressed in musical beats.
Combining Both
A common way to overcome these limitations is to combine both. It is possible to have both MIDI Clock and MTC running at the same time. That’s typically what Blue Cat Audio software uses to keep both the timeline and bpm in sync if you enable both protocols to synchronize our audio applications. Connector also uses this natively so send/receive clock between instances.
There are however gotchas: due to the different nature of both protocols, and the bad timing provided by MIDI clock, it is not always possible to synchronize them together properly, and a BPM change requires a bit of time to be detected by the system and synchronize to the new tempo properly. When MIDI messages are dropped (when syncing through an unreliable network for example), synchronization can be completely lost.
The Blue Cat Audio Hybrid
To solve these problems, Blue Cat Audio software (such as standalone apps, Connector or Fader Hub) uses an hybrid system: as explained earlier, it can already combine MIDI Clock and MTC simultaneously, using MIDI Clock for tempo synchronization and MTC for transport position.
In addition, the system makes use of the standard SMPTE/MTC user bit SysEx message to transmit extra synchronization metadata alongside timecode. This mechanism, originally intended for production identifiers in SMPTE timecode, can carry arbitrary data.
In the Blue Cat Audio implementation, optional BPM information is encoded as ASCII text and split across multiple user bit payloads, for example:
- @BPM
- =101
- .001
These segments are packed as 4 ASCII characters strings (32-bit) into consecutive SMPTE user bit SysEx messages and reassembled upon reception, enabling immediate propagation of tempo changes in parallel with MTC position updates, without breaking existing MTC receivers.
As a result, you can synchronize applications reliably, even when connected remotely thru the Internet via Connector or Fader Hub. This implementation remains fully compatible with standard MTC and MIDI clock implementations.
If you are developing an application, plug-in, or hardware device that relies on synchronization, consider adding support for this extension.
By taking advantage of the additional timing information available, you can deliver a more accurate and reliable synchronization experience for your users.
