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?

FACT: ANY MUSICAL system requiring both a sequencer or drum machine and a tape recorder to be run simultaneously cannot afford to have any significant degree of synchronisation inaccuracy. Fact: while systems for sync'ing these pieces of gear are used every day in studios the world over, they are not without their problems. This article is intended to look at the methods most commonly used for synchronisation involving MIDI, including advantages and disadvantages, followed by the latest timing technology - MIDI Time Code or MTC.

The easiest way to ensure that a system stays synchronised is to have a constant pulse which one piece of equipment (the master) can send out continuously. Any connected device (a slave) will increment its own internal clock by one unit each time a pulse is received, so enabling the two machines to stay in step with each other.

In pre-MIDI days, this was accomplished by using an audio click much like a metronome. If the rate of clicks was slowed down, the tempo also slowed: if the clicks speeded up so did the music.

This is the same principle of operation we use today with the MIDI Clock.

MIDI Clock is a continuous stream of timing pulses sent 24 times each quarter note (24ppqn). As they are note-related, any tempo change will cause the notes to be a different distance apart. For instance, slowing down a piece of music will cause the notes to be further apart, and so the rate of MIDI clock transmission will also slow down. A 'start' signal is sent when the play button is pressed and can be followed by a subsequent 'continue' or "stop" signal depending on what is required.

Syncing up a sequencer to a drum machine, for example, is not a problem as long as the drum machine can transmit MIDI Clock signals and the sequencer can recognise them. However, involving a tape machine in the system gives us a new problem as a tape system isn't capable of reading MIDI Clock information. Consequently, the MIDI pulses have to be encoded into an audio code called FSK (Frequency Shift Keying - which uses an audio combination of two frequencies, usually an octave apart). This normally requires an additional piece of hardware to convert MIDI Clock code to FSK and read it back again off tape - although some devices have the necessary hardware already built in. In a setup like this, the Master device sending out MIDI clock will also have any tempo changes programmed into it, and these will be recorded onto tape as part of the code.

There are two main problems with this system. Firstly, no alteration of the tempo is possible once the code is recorded onto tape. Secondly, the MIDI clocks are relative to the 'start' signal which means that a song always has to be run from the beginning if any slave devices are to run in sync. What is really needed is some kind of locator.

MIDI Song Position Pointer (SPP) is a method of keeping a count of the number of MIDI clocks, in blocks of six, from the beginning of a song. Using such a system you can start the master device (tape recorder or musical unit) in the middle of a song and all slave units will recognise the actual position within the song and lock in accordingly.

Some manufacturers have managed to incorporate this within their implementation of FSK tape sync code (JL Cooper's PPS1 and Musicsoft's Syncman are FSK units that recognise SPP). However, FSK has another major failing. The frequencies used for the tape signal differ from device to device - there is no FSK standard. What is now required is a universal tape code.

$MPTE

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.

MIDI TIME CODE

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.

THINGS TO COME

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.