Like great British comedy, the secret of synchronisation is timing - so just how accurate are MIDI Clock and MIDI Time Code?

SYNCHRONISING YOUR MULTITRACK recorder to a sequencer or drum machine is a delicate affair. On one hand the possibilities opened up by running tape alongside a sequence are endless; on the other there's the danger of hearing your latest song going down the tubes as the sync between tape and computer slowly moves in and out of "focus".

While you can often get away with some movement in synchronisation due to the degree of laxity within the timing of MIDI (courtesy of its serial nature and the response time of many MIDI devices), once you can hear a lack of tightness you know you've got trouble. So, given the option, which of the two main sync systems for MIDI will give you the best results: MIDI Clock or MIDI Time Code?

CLOCK ON

MIDI CLOCK IS a MIDI message ($F8) sent from a master MIDI device. It acts as a digital pulse locking the timing of slave units to the master. Before MIDI arrived, the rate of the (analogue) pulse used for a similar purpose was variable. For example, Roland and Sequential devices used 24 pulses per quarter note (24ppqn) while Linn used 48ppqn and Oberheim used 96ppqn. MIDI Clock is transmitted at 24ppqn and the fact that it is related to the timing of a quarter note is important - it means that the flow of MIDI Clocks is related to the tempo of a piece of music. The higher the tempo, the faster the flow and vice versa. For example, a master device set to a tempo of 120bpm will send out a MIDI Clock every 20.8 milliseconds:

120bpm
= 2 beats per second
= 500ms per beat
= 500/24ms per MIDI Clock
= 20.8ms

If the receiving device had to rely solely on this pulse, there would be serious timing problems due to the loss of integrity of its own internal resolution. A MIDI Note On takes a little less than 1ms to transmit (0.96ms) yet here we are with a clock pulse approaching 21ms requiring the internal timer to wait this long to move to its next step, and so be able to transmit the stored events since the last clock was received. Most of today's sequencers use an internal clock of at least 96ppqn, even the small hardware ones, while sequencers such as Mark of the Unicorn's Performer use 480ppqn. What most sequencers do is to interpolate internally-generated ticks within the MIDI Clocks being received. To keep a sequencer resolution of 96ppqn would entail placing three ticks between each received MIDI Clock.

What does a resolution of 96ppqn mean in practice? Working from the above calculations, 96ppqn will result in internal ticks approximately 5.2ms apart. Each tick cycle allows the sequencer's microprocessor to handle the various MIDI events which have built up since the previous tick. In terms of MIDI, this would mean transmitting about 16 bytes, the content of which will depend on certain considerations; is the sequencer operating in Running Status where the Status byte for a MIDI event is dropped if it is the same as the previous one? Do the MIDI events have two bytes (Program Change, Channel Aftertouch) or three bytes (Notes, Controllers)?

What if you're using pitchbend, for instance? Taking the example of a Roland synth which uses nine-bit pitch wheel resolution, this gives a total of 29 positions = 512. Each position is responsible for the transmission of three bytes, giving a total of 1.536 bytes when the wheel is moved from the centre to the top and back. If a sequencer can only transmit 16 bytes per tick cycle, this is going to take 96 ticks (or 24 MIDI Clocks) to transmit; 96 x 5.2ms = 499ms or approximately half a second. Don't worry, Danno, this is a "worst-case scenario". Using Running Status cuts the number of bytes from 1,536 to: 3 + (511 x 2) = 1025 bytes. Additionally, it should be realised that rapid movement of the pitchbend wheel will not result in all 512 positions being scanned.

In the meantime, what happens to MIDI note information? Some sequencers prioritise MIDI note data, in which case the Note On messages will be given a higher priority than pitchbend. From the point of view of MIDI Clock, Note On information is one of the System Real Time messages which can be sent at any time and can also be sent during other messages, for instance System Exclusive. If this were not the case, it would be impossible to synchronise a MIDI system with any reasonable degree of accuracy. Sequencers are supposed to give System Real Time messages (which also include MIDI Start, Continue and Stop, active sensing and system reset) the highest possible priority.

What happens when a tempo change occurs? Let's look again at an example of a song starting off at 120bpm and slowing to 80bpm for an instrumental break. The original tempo gives MIDI Clocks 20.8ms apart. Assuming our slave sequencer has a resolution of 96ppqn, this 20.8ms gap for each MIDI Clock is divided into four internal ticks, each of about 5.2ms. Of course, the sequencer doesn't know when the next MIDI Clock is going to arrive, so when the tempo change takes place and the MIDI Clock gap changes to 31.2ms for the tempo of 80bpm, what happens? The three interpolated ticks occur and when the next MIDI Clock doesn't appear after 20.8ms, there's an unchartered gap. The sequencer interpolates more ticks at 5.2ms intervals until the next MIDI Clock appears - but the tempo change has already taken place and so the sequencer appears to drag behind the beat. Effectively, the sequencer doesn't react to the tempo change for 31.2ms. If a smooth change of tempo is taking place, the overall effect will be of the sequencer lagging behind, and this may be audible depending on factors such as the tempo changes involved, the number of notes being played and the nature of their envelope (percussive sounds are more likely to give noticeable delays). Yes, we are dealing with small values of time, but most software writers make a big deal out of the high resolution of their sequencers - which gives improvements in terms of similar small values of time.

There are various other anomalies concerning MIDI Clock. The master has to send a MIDI Start command followed by MIDI Clocks when Play is pressed, but how long a gap is left between the Start and the first MIDI Clock? The MIDI Specification states that at least 1ms should be left, but we have to consider how long the slave takes to prepare for that first MIDI Clock? If it misses it, the entire song will be offset by one clock. A similar problem arises when a slave receives a Song Position Pointer (a count of how many 16th notes have elapsed since the beginning of the song) and then can't respond before the first MIDI Clock following this. Remember, unlike SMPTE, which uses unique messages to identify each point on tape, each MIDI Clock looks like any other.

These problems (and others) shouldn't occur, however, and are down to manufacturers' implementation of the MIDI spec. But the fact that they can exist at all is purely down to the nature of MIDI Clock.

CODING UP

MIDI TIME CODE was added to the MIDI spec in 1986 to allow for accurate reference to SMPTE (or LTC - Longitudinal Time Code), the standard for tape time code. Because it encodes the actual SMPTE time into eight, Quarter-Frame messages it is an absolute measure of time as opposed to MIDI Clock and Song Position Pointer which are relative measures, dependent on tempo. For audiovisual work in particular, tempo is often not a factor - cues occur at specific time points - and so a non-tempo based system is essential.

Quarter Frame messages are used both as the "pulse" for the system, and to allow the actual SMPTE time to be encoded and then decoded by the sequencer. Each of these messages is two bytes long, consisting of a Status byte ($F1) followed by a Data byte. So, at least two frames are needed whenever the system starts to identify the precise time. Working at 25 frames per second, this would take 80ms - far too long. For this situation, a Full message is used, which transfers the complete time in a ten-byte message.

What problems are there with MTC? Firstly, as it takes two frames to decode the time, the slave unit needs to keep a permanent internal offset of two frames. Secondly, the time isn't actually transferred until the second byte of the Quarter Frame message has been received. This effectively leaves the receiving device at least 0.64ms behind. This can be dealt with by either sending the messages early or by compensating within the slave. As the slave is working in hours, minutes, seconds, frames and bits, a calculation is required as to how many bits to back up. The problem here is that this depends on the frame rate; the fact that SMPTE to MTC converters may not necessarily read the SMPTE code bit by bit (80 bits = 1 frame) but by frame edge, SMPTE byte or other method doesn't help. While these elements have to be dealt with, they rarely involve unknown timing factors such as those which occur with MIDI Clock.

The only problem with MTC which cannot be solved is that as a Quarter Frame message incorporates a Data byte, the message cannot be inserted into other MIDI messages. Consequently, if a manufacturer is running background SysEx messages to update certain aspects of a MIDI device, MTC cannot be used. One possible answer is for manufacturers to break down SysEx messages into smaller packets.

Q&A

ARE THERE ANY situations where the use of MIDI Clock is preferable to MTC? How about the timing of the "pulse" - MIDI Clock or Quarter-Frame message? For instance, at 25 frames per second, a Quarter-Frame message occurs each 10ms. What tempo would you need to get MIDI Clocks to be that frequent?

"x" beats per minute = "x"/60 beats per second
= 60/"x" seconds per beat
= 60,000/"x" ms per beat
60,000/24"x" ms per MIDI Clock
= 2,500/"x" ms per MIDI Clock

If a MIDI Clock has to occur each 10ms, the tempo must be greater than 250bpm, a situation which rarely (if ever) occurs. More to the point, the slave knows precisely when the next Quarter Frame message is going to appear, thus making internal clock interpolation a far more accurate process.

Is MIDI Clock simpler to work with? In short, it isn't; if you're using FSK instead of SMPTE as the tape sync code, you cannot change the tempo or length of a song once the timecode has been recorded. With SMPTE, the usual procedure is to "stripe" the entire reel of tape in one pass. If a SMPTE-to-MIDI Clock converter is being used, tempo changes have to be keyed into the converter. With a SMPTE-to-MTC converter, the tempo track on the sequencer handles tempo changes. This has to be the easiest and most flexible way to work.

Given the choice, MTC has to be selected over MIDI Clock - indeed, it's the standard for practically all current Apple Mac sequencers.

The question is, out of all of the sequencers available on the Atari ST, why are Steinberg and Passport the only software companies who have implemented MTC?