My Life With MIDI Time Code
Just as MIDI itself has gone far beyond what its developers imagined, so MIDI Time Code has the potential to take MIDI technology into areas quite removed from the synthesis and sequencing worlds in which it has become so familiar. MTC user Paul D. Lehrman explains how.
I use MIDI Time Code. I use it a lot, and have been for nearly two years. That's why I was completely taken aback and a little appalled by Chris Smith's 'Sounding Off' piece, entitled 'Whatever Happened to MTC?', in these pages a couple of months ago [SOS October]. I can't believe the state of synchronisation in Britain is as bad as Chris says it is, and that MIDI Time Code (MTC) is such a rarity. If it is, you Limeys are in serious trouble. But I know you're not.
In his article, Chris says he has "yet to see a working system in which MTC is implemented." This means he's never seen my back bedroom, which, considering I live about 4000 miles away from him, isn't surprising. But I'm not unique - there are thousands like me here in the States who are using MIDI Time Code every day with sequencers, hit-list generators, effects editors, and hard disk recording systems. And I'll let you in on a secret: it works great.
Of course, like anything else technological, MIDI Time Code has its ups and downs, its ideals and its realities. As a concept, it's fully realised. As a working standard, it's still in flux. A lot of parts of it remain unexplored, or ambiguous, but it's already doing wonderful things, and it will soon be doing more.
So here are a few thoughts about what MIDI Time Code is, what it's doing for me and can be doing for you, and what we can expect from it in the future. Some of these thoughts stem from my personal experience, some come from what others have told me. Some of them might even turn out to be wrong. But you'll never know until you try it.
Now listen up. Elvis is dead, there is no Santa Claus, and 'MIDI Time Code' and 'MIDI Sync' are not the same thing.
When we talk about MIDI Sync, we're actually referring to several different MIDI commands or messages: 'Timing Clock', which is a single byte sent 24 times per quarter-note, and is therefore (and this is important) tempo-dependent; 'Song Position Pointer', a three-byte message that tells a sequencer where to start, by counting the number of 16th notes since the beginning of the piece; and 'Start', 'Stop', and 'Continue'.
When it comes to synchronising with tape, MIDI Sync is used in two different ways. One way is with a SMPTE/EBU timecode stripe and a hardware convertor, like the Roland SBX80. You tell the synchroniser where on the tape (ie. at what SMPTE number) you want your sequencer to start, and enter that number into the convertor as a 'start time' or 'offset'. Then you decide what tempo and meter you want the sequence to play at, and enter that.
As the tape plays, when the convertor encounters the SMPTE number you've programmed as the start time, it sends out a Start command, and follows it with Timing Clocks at the speed corresponding to the tempo you've programmed. If you start the tape later, the convertor takes the first SMPTE number it encounters and calculates the bar and beat of the sequence that the number corresponds to, using the start time and the tempo information to do the arithmetic. It then sends out a Song Position Pointer to the sequencer, followed by a Continue command, and then Timing Clocks at the appropriate tempo.
If you want to change the tempo during a piece, you have to enter the new tempo into the convertor, along with the number of the bar and beat at which you want the tempo to change. Now the convertor will generate Timing Clocks at the right tempo at that point, and it will also be able to compute Song Position Pointers after that point correctly. Every tempo change has to be entered individually, and the list of changes for a piece is known generically as a 'tempo map'. If you want to make any changes in an existing tempo map, you have to do them one at a time.
The other way to sync from tape with MIDI Sync is with an audio signal known as 'FSK'. You generate FSK by setting up a sequencer with an internal tempo map, and then sending Timing Clocks from the sequencer to an FSK generator. The generator produces an audio signal which is frequency-modulated in step with the Timing Clocks, and which you can record on tape. When the tape is played back, the FSK signal triggers the convertor to produce Timing Clocks, which the sequencer follows.
As the tempo in a sequence changes, so does the modulation rate of the FSK signal. The FSK signal records the tempo information permanently - once the track is down on tape, you can't change any of the tempo information it contains without re-recording it from the very beginning.
Once upon a time, you could only use FSK if you always started the tape and the sequencer from the beginning - there was no way an FSK track could tell you where it was, only what tempo it was supposed to be running at. Nowadays several manufacturers are making 'intelligent FSK' boxes which encode Song Position Pointer information into the FSK code, so that you can start and stop anywhere, and the sequencer will follow. Changing tempos after a track is laid down, however, is still impossible.
Okay. Now what MIDI Time Code does is something quite different. MIDI Time Code is generated from a box that reads SMPTE timecode. SMPTE goes in, MIDI goes out. That's it.
While SMPTE data comes out in a continuous stream of analogue data, MIDI Time Code comes out in little digital bursts. These bursts occur four times for each SMPTE frame (which translates to 96, 100, or 120 per second, depending on your SMPTE format) and are known, not surprisingly, as 'quarter-frame messages'. Each quarter-frame message contains two bytes, the first of which (similar to most MIDI commands) is the 'status' byte, which says 'I am MIDI Time Code', and the second of which is the 'data byte', which says 'Here's my location'. You can't get an entire SMPTE location into a single data byte, so successive quarter-frame messages contain different parts of the location number, known as 'nibbles'. It takes eight quarter-frame messages to contain all of the data for an entire SMPTE number. Therefore, the receiving device has to get two full frames of MTC data before it knows where it is. But the quarter-frame messages do have a use by themselves - they act as 'clocks', running at a constant speed of 96/100/120 ticks per second, in a tempo-independent fashion.
A device like a sequencer, reading the MIDI Time Code produced by a SMPTE-to-MTC convertor, knows the location of the tape at any instant. Also, by looking at the speed of the incoming quarter-frame messages, it knows the speed of the tape - if the transport slows down or speeds up slightly (as all tape machines do), the MTC will change accordingly.
The starting time and tempo information for the sequence are stored inside the sequence itself - when you start the tape rolling at any point, the sequencer cleverly calculates from the MTC what measure and beat to start at and what tempo to run at.
This has three major advantages. First, setting up tempo changes in a computer-based sequencer is much easier than doing it on a device like an SBX80. Most good sequencers let you perform tempo tricks like create smooth accelerandos and ritards, or fit a certain number of beats into a certain length of time, or create a complex tempo and beat pattern that runs over several bars and repeat it many times, or even run different tracks at different tempos. When using MIDI Time Code, you can utilise all of these features, letting the computer worry about making sure the numbers are exactly right. With an external synchroniser sending MIDI clocks, performing those same functions requires a calculator, a click book, and a lot of patience, if you can do them at all. (Figure 1.)
The second advantage is that because the sequencer's internal tempo map is always being used, you can listen to the sequence without the tape running and hear exactly the same thing you would with the tape running. When you're editing a sequence, it is usually much easier just to use the computer's locating functions to go back and check what you're doing, without having to rewind the tape, roll it, and wait for the synchroniser to catch up each time you want to hear what you've done.
The third advantage has to do with what happens when sync is momentarily lost. With Clocks and Song Pointers, once an initial start time is sent and the clocks commence, the sequencer is on its own. If a clock byte gets accidentally scrambled or lost, the sequencer will never know that something bad has happened, and will go merrily along, now permanently out of sync with whatever is feeding it. (This is also a problem with 'Direct Time Lock', a pre-MIDI Time Code protocol used by Mark Of The Unicorn's Performer, a Macintosh sequencer program.)
MIDI Time Code, however, is constantly telling the receiver what time it is, and so a lost byte can be discovered quickly, and the sequencer can get itself back in sync without stopping and starting the tape. In fact, because MIDI Time Code can be used without Start and Stop commands, an MTC-based sequencer can even be started after tape is rolling, which is impossible with conventional MIDI sync, because a tape that's moving will not generate a Song Position Pointer.
Before we leave MIDI Time Code's advantages, let's realise that one disadvantage you may be worried about isn't going to happen. MTC will not make all your old drum machines and hardware sequencers obsolete. Once a computer sequencer is locked to MIDI Time Code, it can easily be called upon to generate MIDI Clocks and Song Pointers based on its own tempo map at the same time, and this can then be used to drive any pre-MTC device you might have. And because the SMPTE-to-MIDI conversion is occurring at only one point, there is less room for sync error than might occur in a situation where multiple devices are all trying to derive their own timing information from a SMPTE signal.
Using sequencers in conjunction with video or audio tape is just part of MIDI Time Code's usefulness. It's a great way to get SMPTE numbers into a computer for any purpose. Digidesign's Q-Sheet, an event-list editor for sound effects and studio automation, couldn't run without it. With Q-Sheet (which is really a sequencer that uses SMPTE numbers instead of bars and beats) and MTC, you can tell a sampler with a gunshot in it to fire at 2 minutes, 45 seconds, and 4 frames, which is the same number that shows in the timecode window on the screen when the smoke comes out of the barrel. With a sequencer that only reads conventional MIDI, you would have to set your convertor to 4/4 at 120 bpm, and then calculate that the gunshot should occur on measure 82, beat 3, clock 60. Imagine doing that for every effect in a two-hour film.
Hit-list generators like Opcode's Cue and Passport's Clicktracks rely on MIDI Time Code to set up tempo maps for visual cues, and transport the maps over to sequencers for fast scoring. They use standard MIDI Files for the transfer - if they had to get the tempo maps into hardware synchronisers, they would have to know the System Exclusive format for every synchroniser on the market.
Sound Tools, the hardware and software package from Digidesign that turns the Apple Macintosh into a fully-fledged digital audio workstation, depends on MIDI Time Code for communicating with the outside world. When the system is told to record a section of an incoming audio signal, such as a line of dialogue or a location-recorded sound effect, it knows where to start and stop recording by the section's MIDI Time Code numbers. When it plays back a track while slaved to an audio or video tape deck, that slaving is accomplished through MTC.
When Apple's MIDI Manager, a musical multitasking system, begins to appear on Macintoshes over the next few months, it too will depend on MTC. The system will be able to run sequencers, effects-list editors, algorithmic composers, and direct digital playback from RAM and/or hard disk all at the same time, and the common link for all of these programs will be MIDI Time Code.
MIDI Time Code is not perfect. Like any new technology, it has some problems and creates some challenges for those who wish to use it. The most talked about drawback is the amount of MIDI bandwidth the commands take up. It's well known that if a MIDI cable is asked to carry too much data, it slows down, and the music coming out of it can sound jerky and out of sync. Does MIDI Time code contribute to this problem?
Chris Smith did some arithmetic in his article [p. 104, SOS October], and it is basically correct. MTC within a MIDI stream only adds approximately an additional eight percent to the load. But that figure tells only part of the story. Many sequencers take advantage of a part of the MIDI spec known as 'running status'. Running status allows you to speed MIDI up by eliminating the need to send redundant status bytes (the first part of every MIDI command) wherever possible. If you put a MIDI Time Code message in the middle of a pitch bend sweep, for example, running status is interrupted, and a new status byte has to be sent after the MTC message. So instead of inserting two extra bytes (the length of the MTC message), you've now inserted three. Therefore, the overhead is potentially increased not by eight percent, but by 12 percent.
But actually there's a more serious problem than how MTC interferes with conventional MIDI commands: it's how conventional MIDI interferes with MTC.
The quarter-frame messages are as accurate, if not more so, as MIDI Timing Clock commands (it takes a tempo of 300 beats per minute to generate MIDI Timing Clocks at the 120-per-second rate of MTC). But this also means that devices reading MIDI Time Code will be more sensitive to timing information than those reading simple Clocks. Because an MTC message is two bytes (as opposed to the Clock's one byte) and because the MIDI data stream is full of other messages of varying lengths (including System Exclusive messages, which are finding more usage in sequencers, and which can be very long indeed), the MTC message can get pushed around slightly. This results in a form of digital 'jitter', and can have a small but noticeable effect on the timing of any device slaved to the MTC data.
These reasons are why it's considered good practice to have MIDI Time Code on its own MIDI cable, separate from conventional MIDI data. In fact, at least one sequencer on the market forces you to keep the streams separate.
When MIDI Time Code first came out, a lot of folks pooh-poohed it by saying that it wasn't as accurate as SMPTE timecode, and therefore wasn't usable in 'professional' situations. They were missing the point: there's no reason for MTC to replace SMPTE when it comes to synchronising mechanical devices like tape decks. But when it comes to driving MIDI gear, MTC is as accurate as MIDI, and is therefore of tremendous use. Since those early days, however, rumours have surfaced of tape decks that can sync to MIDI Time Code. These rumours have been false, and will always be so. You don't want to sync a tape deck to MTC, not ever.
Even on a dedicated line, MTC will experience some jitter, because the resolution of MIDI is not infinite. A device reading SMPTE timecode on tape can be phase-locked, so the resolution can be as accurate as the rise time of the SMPTE signal, and that resolution is checked each time a bit comes in, which is up to 2400 times every second. MIDI resolution has an upper limit of about 0.6 milliseconds, and since the quarter-frame messages come in no faster than 120 times per second, any corrections made would be much coarser. While MIDI's resolution is fine for sequencers, it is no good for analogue tape, because we would hear the changes as flutter — the human ear is much more sensitive to minute changes in pitch than it is to changes in rhythm. As one engineer I know puts it, slaving your tape deck to MTC would make it sound like "a cheap cassette deck whose batteries are running low."
On the other hand, there is a way that MIDI Time Code can be used to control tape decks, and that's to send location information to them. If you are using a sequencer, and moving around to listen to different parts, wouldn't it be nice if your tape recorder could follow, instead of the sequencer always being forced to follow the tape?
MIDI Time Code incorporates another message type, known as 'Full' messages, which sends the entire SMPTE number at one time, and is supposed to be used whenever you change a location on a tape without putting the tape into Play mode. But this can work the other way around: a sequencer could generate a Full message every time you moved the location cursor, and a tape deck could respond to it and automatically wind the tape to the location in the message. Of course, once you started up the tape, the roles would have to be reversed, and the sequencer would have to slave to the SMPTE timecode coming off the tape. Is this possible? Several manufacturers are working on it, and there is a proposal in front of the MIDI Manufacturers Association to make this kind of machine control a permanent part of the MIDI spec.
Theoretically, SMPTE-to-MTC conversion should be a completely straightforward task, and therefore every device that accomplishes that task should be the same. Unfortunately, this is not quite true. There are a number of SMPTE-to-MTC convertors available that just send quarter-frame messages, and never send Full messages. Their designers figured folks would only be using them to sync a sequencer to a tape using a conventional linear-recorded SMPTE stripe, which can only be read when the tape is moving forwards at normal speed anyway, so the quarter-frame messages should be adequate.
Those devices may soon present problems. They would be useless in the transport-control scenario just discussed. They would also have a very hard time dealing with VITC ('vitsy': Vertical Interval Time Code), which is a form of SMPTE which can be read while the tape is standing still or moving at almost any speed, forwards or backwards. VITC is becoming fairly common, even in modest post-production studios. If you convert VITC to MTC, you can make a sequencer go along with a tape at very fast speed, or even run backwards. Its greatest use, however, will be letting you determine hit points for music and sound effects by rocking the video tape, and then telling the computer to grab the number of the frame it sees. This is impossible unless the convertor sends full MTC messages, not just quarter-frame messages.
With different software programs, MIDI Time Code doesn't always behave the same way. For example, if you think about it for a moment, you'll realise that MIDI Time Code is always running behind. Since it takes two frames (eight quarter-frame messages) to send a complete SMPTE number, by the time the number is received, it's two frames later. This constant offset should be built into any software that reads MTC, or else nothing will ever line up correctly. However, the designers of one of the first programs to read MTC apparently forgot this, and things were pretty weird for a while!
Even if it is reading the code properly, there can be differences in the way programs interpret MTC. When I talked about MIDI Time Code's ability to catch up with lost data earlier, I didn't tell the whole story. Exactly how this is accomplished will vary from program to program, just the way different tape synchronisers behave differently when they have to deal with off-speed tape decks. If an MTC-based program starts to run too fast, or a byte gets lost somewhere on the way in, the program has to know what's going on and make adjustments accordingly.
Different programs will use different algorithms to accomplish this 'chasing' function, and some will work better than others. Some may check the code every 10 frames, while some may check it every beat, and others may only check it once every measure. If the algorithm is well-designed, its action should be inaudible, but if you are running two MTC-based programs together that use very different algorithms, you may actually hear them go in and out of sync.
There is another MTC issue that the user has to be aware of. What happens if the SMPTE code on the master tape drops out momentarily? This is extremely common, especially on the consumer video recorders and small-format multitracks used by many small studios. Some convertor boxes include an electronic 'flywheel' that keeps generating MTC for a second or so after SMPTE is lost. Some software programs do the same thing: if the MIDI Time Code coming in drops out, the program will keep going, using its internal clock, for a period of time until the MTC is restored. Both options work well, but ideally they should be defeatable, so that when you are using a tape with good code, you don't have to wait for the sequence to stop every time you stop the tape.
No doubt you have noticed that all of the programs I've mentioned so far in this article run on the Apple Macintosh. That's because Macs, as we shall see, lend themselves more readily to MIDI Time Code applications than Ataris, IBMs, or Amigas. This fact, combined with Apple's extortionate marketing and pricing policies in Britain, is at least partially responsible for MIDI Time Code's apparent slow rate of acceptance in the UK. But there's still plenty of activity in the Atari and IBM camps, and there's more to come.
Because of potential bandwidth problems, most manufacturers have decided that if users are going to accept MIDI Time Code, they will have to bring it into their machines on a port separate from incoming MIDI music data. The Mac can handle this readily - it has two serial ports, so you can connect MIDI interfaces to both of them and devote one of them to incoming MTC.
Atari STs, of course, already have a MIDI In - but many manufacturers are reluctant to squeeze MIDI Time Code into it. Passport Designs' MIDI Transport for the ST provides an external interface for bringing MTC in through the computer's serial port. Steinberg's SMP24 does the same thing, although it also allows MTC to come through the Atari MIDI port. Not surprisingly, Passport's Master Tracks Pro and Steinberg's Cubase are the only two major Atari Atari sequencers that respond to MIDI Time Code. Other SMPTE-to-MIDI convertors for the Atari, like Dr. T's Phantom and C-Lab's Unitor, don't use MIDI Time Code, but instead use proprietary timing codes to bring the SMPTE information in through the serial port. While these work well, and provide many of the advantages of MIDI Time Code to the user, they will only work with software specifically designed for them.
IBM PC users have a different problem. The 'industry standard' PC MIDI interface is the Roland MPU401. Most programs that use the MPU401 take advantage of its 'intelligent' mode, in which the unit keeps track of timing and various other housekeeping chores, thereby allowing the software to run faster and simpler. Unfortunately, because the MPU401 predates the introduction of MIDI Time Code, it does not allow MTC messages to pass through, filtering them out as so much junk.
One or two programs use the MPU401 in 'UART' (interface only, no intelligence) mode, and these work just fine with MTC. Music Quest, a Texas company, has several interfaces on the market that offer MPU401 emulation but also allow MTC messages to pass. Programs that recognise this interface, which include Forte II, 64-Track PC, Cakewalk Professional, and (by the time you read this) Texture, will work with MIDI Time Code.
Passport's MIDI Transport will also work with a PC, in which case it merges the MIDI Time Code and other MIDI messages into one serial port, but communicates with the computer at very high speed, so there are no bandwidth problems. (It works the same way with the Commodore Amiga.) Other companies are planning similar hardware solutions for the near future so that they can free themselves from the MPU401, which one developer refers to as "our albatross".
Another solution is represented by the Yamaha C1 music computer, ostensibly an IBM clone, but with its own built-in MIDI and SMPTE interfaces. The C1 uses a completely different protocol than the MPU401, and most programs written for it will respond to MIDI Time Code.
Just as MIDI itself has gone far beyond what its developers imagined, so MIDI Time Code has the potential to take MIDI technology into areas quite removed from the synthesis and sequencing worlds in which it has become so familiar.
One reason for this is that, although few are aware of it, the MIDI Time Code spec includes a whole other set of commands besides the 'real-time' quarter-frame and full messages. These are known as 'Cueing' messages, and so far nobody has implemented them in hardware or software.
What Cueing messages can do is to turn MIDI into a kind of 'Device Control Language' in which whole sets of complex time-based commands can be sent to various devices around a studio before tape is rolling, to tell them that when they receive a certain MIDI Time Code number (after the tape has started), they should perform a certain operation. The idea is based on the assumption that there is a finite (although quite large) set of functions that any device you might find in a studio can perform, and therefore one set of commands can be used that will cover all these possible functions. Every device will respond to the command set in the same way: the same 'Play' command can be recognised by a video recorder, a CD player, a sequencer, or even a turntable.
A very simple example would be pre-programming a multitrack tape machine to do multiple punch-ins and punch-outs at different times on different tracks, in one pass. Before you start the music, you send a list of Cueing commands to the tape machine that specify all the punch-in/out times. The machine receives those messages and stores them in its internal memory. When you start the music, the tape machine only has to receive MTC, not any actual commands, and it executes the punches at the specified times.
This idea can be expanded for use with any audio or video device: recording, playback, processing, mixing, or what have you. If you've ever worked with SMPTE-based console automation systems, this will sound familiar. With those systems, however, you have to programme each individual device to do its thing at the right SMPTE time, and send SMPTE to all of them. With MTC's Cueing commands, you can programme everything from one central controller - your computer - and then convert the SMPTE at just one point, and send MIDI Time Code around the room.
Here's a more complex scenario: you're doing a film soundtrack, and you've got effects coming in from CD players, music from sequencers, Foley sounds from a sampler, and dialogue from a hard disk recorder. The director comes in and declares that he's just cut 14 frames from the beginning of the scene. You can accommodate him immediately, reprogramming all of the devices (not to mention your mixing console automation) by simply making adjustments in the cue lists on your computer screen, and sending the new lists to all the hardware in the form of MTC Cueing messages.
The use of MIDI Time Code doesn't have to be restricted just to music production. There's no reason why real-time and Cueing messages can't be used to synchronise and automate video systems, theatrical events, multimedia, museum displays, robots, interactive advertising displays, or anything at all that can be controlled digitally and relates to time. All it takes is for more manufacturers to realise the potential of MTC, and to start tapping into it.
So to answer Chris Smith's question, MIDI Time Code is alive and very well, thank you, and living in MIDI production systems all around you. It has made my life easier in more ways than I can count, and someday it will do the same for you.
Paul D. Lehrman is a composer, author, consultant, and educator based in Boston, USA, who is devoting much of his life to writing incredibly inexpensive film soundtracks that sound incredibly expensive.