Adrift On An MTC
MIDI Time Code
MIDI Time Code, an overdue MIDI sync standard or a missed opportunity for musicians and manufacturers alike? Vic Lennard finds out what time it is.
ADEQUATE SYNCHRONISATION IS ESSENTIAL TO MODERN MUSIC STUDIOS BOTH LARGE AND SMALL. MIDI TIME CODE OFFERS TO HELP SIMPLIFY SYNCHRONISATION BUT WILL IT RECEIVE THE SUPPORT IT REQUIRES?
THE ORIGINAL USE of a universal sync code was in the film industry for locking together two tape machines for editing purposes. As such, the Society of Motion Picture and Television Engineers (hence SMPTE) designed four formats which encoded actual time in hours, minutes, seconds and frames. The only difference between the formats is the number of frames per second which varies depending on the application. For instance standard motion picture rate is 24 frames/sec while European TV is 25 frames/sec. From an audio point of view, there is little difference although the same frame rate chosen for record must also be used for playback.
From a MIDI standpoint, SMPTE provides a standard, and as such there are perhaps a dozen different devices which will read/write SMPTE to tape and convert to MIDI clocks and song position pointers. Unfortunately, there is no universal way of converting from SMPTE to MIDI and so timing errors occur if you write the code to tape with one device and then playback, and hence convert, via a different one. Also as SMPTE deals with absolute time, it takes no account of initial tempo and tempo changes which have to be keyed into a table within the synchroniser.
Once you start to venture into the audio-visual domain, the problem is further magnified. In MIDI sequencing we tend to work in beats and bars, while in film and video the main criterion is real time in hours, minutes, seconds and frames. Continuously having to convert between the two can be an nightmare. Our latest requirement, then, is a way of encoding SMPTE within MIDI messages.
AN MTC GENERATOR reads and writes SMPTE to and from tape, and creates the MIDI messages necessary to synchronise any piece of equipment which will recognise MTC. Tempo information will be programmed from within the slave device.
There are two basic types of MTC message:
A quarter frame message is used while the system is actually running, and so is analogous to MIDI clock. The important difference is that actual time is encoded into MIDI information within a group of eight MIDI messages, each two bytes long. Each message starts with a MIDI status byte (F1) and is followed by one data byte, the first of the group being 0X, the second 1X up to 7X for the eighth, where "X' corresponds to the data for the time. The first two of these messages represent the number of frames, the next two the number of seconds, then minutes and finally hours.
"IN MIDI SEQUENCING WE TEND TO WORK IN BEATS AND BARS, WHILE IN FILM AND VIDEO THE CRITERION IS REAL TIME IN HOURS, MINUTES, SECONDS AND FRAMES."
Let's take an example. Suppose that 01:38:24:20 at a frame rate of 30 frames/second had to be encoded. First of all, the numbers would be converted into hexadecimal (base 16), then the two digits reversed because the units part of the hexadecimal is coded first and then encoded into the four pairs of messages as follows:
F1 04, F1 11; 14 Hex = 20 decimal = number of frames.
F1 28, F1 31; 18 Hex = 24 decimal = number of seconds.
F1 46, F1 52; 26 Hex = 38 decimal = number of minutes.
F1 61, F1 70; 01 Hex = 01 decimal = number of hours.
However, the frame rate also has to be included. As the final pair show the number of hours which will have a maximum value of 23, the rate is encoded within these two bytes as well. The final values would be:
F1 61, F1 76
(For those interested, the frame rate is encoded into bits 5 and 6 of the final byte).
As eight Quarter frame messages are needed to completely encode the time, all eight of these will have to be read before the time can be decoded. This takes two frames (8x 1/4), and so the data at that point will actually be two frames old. Consequently, a slave has to keep a permanent internal offset of two frames.
Why not use four messages instead, each of four bytes, which could be sent in the time of one frame? Well, consider the maths of the above with eight messages; a MIDI byte takes 320 microseconds to travel over MIDI, so at a frame rate of 25 frames/second, two bytes (0.64 milliseconds) will be sent every 10 milliseconds. This is equivalent to 6.4% of the available MIDI bandwidth. Using four messages instead of eight would double this percentage and so be unacceptably high.
Is MTC inherently too inaccurate for work with film/video where frame accuracy is required? Taken out of context, the answer would probably be "yes", but slave devices are intended to interpolate SMPTE time in between the two frames required for the decoded time from tape. This is similar to the process used by many sequencers in dealing with MIDI clock which only has a resolution of 96ppqn.
A Full Message (ten bytes) is used when the complete time is needed in a single message. This would be necessary after rewinding or fast-forwarding through a tape because the delay in waiting for at least two frames to pass before locking up would be too long. Quarter frame messages would then take over.
There are two other types of message. The first of these is the User Bit Message (15 bytes) which can be used for special functions like putting a date to a code or numbering reels of tape. It is likely to be used only once at the start of the code. The second is rather more interesting. Set-Up Messages (13 bytes) deal with setting and activating punch in/out points, event start/stop points and cue points. They can form the basis of a fully automated system via a Cue List Manager, a separate piece of hardware or computer program that would keep a list of all necessary alterations during a performance. The required information would be transmitted to slaves by these messages.
THE SUCCESS OF MTC lies in the hands of software and hardware designers. XRI Systems have brought out the XR20, a stand-alone MTC generator, and upgrades for their XR300 to make it capable of transmitting MTC. Interest within the Atari-based software companies is mixed. Steinberg's Cubase can already recognise MTC (but Pro24 will not) while updates to Hollis Research's Trackman and Digital Muse's Virtuoso will also support it. C-Lab will not be implementing MTC within either Creator or Notator, although they are intending to be able to transmit MTC from the Atari MIDI Out port in an upgrade planned for next spring. Hybrid Arts have no intentions concerning MTC.
The lack of any real enthusiasm from many of the software companies is understandable. Most of them already sell hardware SMPTE devices which inject timing data straight into the program via external ports on the computer, and as such are bound to give better timing accuracy than MTC. However, if MTC is to be accepted as the new MIDI timing standard then future upgrades for all relevant software and hardware should be compatible with it. Otherwise yet another attempt at establishing a "standard" will go the same way as those for System Exclusive and MIDI Sample Dump - different for each manufacturer. Our future is in their hands.
Feature by Vic Lennard
Previous article in this issue:
Next article in this issue:
mu:zines is the result of thousands of hours of effort, and will require many thousands more going forward to reach our goals of getting all this content online.
If you value this resource, you can support this project - it really helps!