A QUESTION TIME
Mar 1, 2005 12:00 PM, BY JOHN McJUNKIN
Timing is everything, so the saying goes. And in music production, it's definitely true. I don't know how many producers and engineers I've seen fussing over absolute precision in automating levels, compression, EQ and effects while completely disregarding timing. “Why don't my mixes sound tight and clear?” they ask. Miniscule synchronization problems cause tiny delays in the arrival of a signal at your ear. Sometimes, this creates a pleasant thickening, or the delay may even be long (and “wobbly”) enough to create groove, but it is far more desirable to have control of such things rather than cast the fate of your mix to the wind. Although some sync problems will remain static and consistent throughout your music, some other particularly insidious problems cause the timing to get further out of whack as playback continues. Indeed, accurate synchronization is every bit as important as having accurate monitors in your studio. Examining some of the issues associated with MIDI synchronization will hopefully help you to tighten things up a bit.
CLOSE ENOUGH
MIDI is now officially old enough to have a beer — it was introduced 21 years ago. Back then, bandwidth requirements were minimal, but, nowadays, you can cram a lot of stuff (particularly continuous-controller data) down a pretty narrow pipe. Nonetheless, MIDI is still a viable way to accomplish your goals if you do it right. MIDI data invariably arrives late due to hardware and software; the question is how late. If your MIDI notes are driving a synth playing a spongy pad with a slow attack, the latency will probably be imperceptible, but anything with a fast attack can suffer greatly, even with less than 10 ms of latency. If your drums are smack on time, a delay in a percussive bass can be painfully noticeable. For that matter, this entire discussion applies almost exclusively to sounds with a fast attack. When it comes to such things, precise timing is important. Follow the data on its journey to figure out where you can make improvements.
OPTIMIZE THAT COMPUTER
I'm going to presume that a computer is the location that your MIDI transmission starts. This is indeed the case more than 90 percent of the time. I'll also presume (rightfully so) that there is really no significant latency or jitter at this stage. And let me define these terms: Latency refers to the actual amount of lateness with which the events arrive. Jitter refers to inconsistencies in the latency: Some events arrive only a little late, and others arrive really late — a definite problem! The data leaves your computer (via software) through a port, which is either USB with newer computers or serial or printer if you're using an older machine.
The software that comes into play is the operating system's MIDI driver. You'll want to make sure that your hardware interface (USB or otherwise) is up to snuff and that the driver software is optimized. You don't want to choke your MIDI interface with too much data, but you also want to get as much data through as necessary. Your interface's manual will detail how to optimize the driver. Some sequencer developers now sell interfaces that are optimized for use with their specific applications. The way they work is to send a bunch of MIDI data via USB to the interface, store it momentarily in a RAM buffer and then kick it along to your MIDI devices in an extremely precise way based upon an internal low-jitter clock; examples include Emagic's AMT8 and Unitor8, Steinberg's Midex 8 and nearly all of MOTU's interfaces. These enable extremely high precision and nearly nonexistent jitter. Using an optimum interface paired with your application is among the best things you can do for yourself to solve MIDI-timing woes.
Also, dedicate a highly optimized computer to audio and MIDI if possible, or set up an audio/MIDI account if your operating system allows it. Most computers have a lot of extraneous software that is useful to housewives or accountants but not to electronic musicians. Eliminate it (but only after a thorough backup). You should also disable applications that run in the background, like virus checkers. They use a significant amount of your CPU's capacity and are harmful to MIDI accuracy. Disable hardware devices that are not used in music production (even internal soundcards if you're not using them). Get rid of any unimportant cards in PCI slots or other unnecessary devices connected to the computer. Maximize RAM and hard-drive space, and optimize and defrag your drives. Get rid of screensavers or any fancy graphics effects associated with the system. These things chew up clock cycles, as well.
THE MIDI INTERFACE
The next stop is the MIDI interface itself. This converts data from the computer into something your synths, samplers, drum machines and groove boxes can understand. The typical MIDI Note On command takes approximately 1 ms to transmit, and because MIDI is a serial protocol, these messages must be transmitted one after another. If too much data is transmitted in too short of a time frame, your sound modules can become confused and react badly. One other helpful hint: Drum machines can get squirrelly as a result of an overload of MIDI data; a Note Off command accompanies every Note On command, and if they're not spaced far enough apart, a large burst of data is quickly transmitted to the machine, causing a hiccup or even worse. A solution for this is to avoid supershort notes in your computer sequencer. Let the sound module take care of the sound's envelope, allowing the MIDI Note On command to simply trigger the notes. Don't send a 128th note to trigger something that will actually play back an eighth note.
BREAK THESE CHAINS
Each of the MIDI Outputs on your interface can handle 16 channels, and, theoretically, you can thus daisy-chain as many as 16 devices on a single output, each “listening to” its own channel. In addition to the minimum 1 ms required to transmit each Note On, each device in the chain introduces latency. By the time a Note On gets to that last device in the chain, it's going to be significantly late. For this reason, I strongly recommend to not daisy-chain if you don't have to. Multi-input/-output MIDI interfaces are simply not that expensive these days, and the gains you'll make in timing are well worth the money.
If you must daisy-chain, put any drum machines, percussion modules or anything else that makes transient or percussive noises first in the chain, followed by other devices that are more likely to be used for pads and other sustained notes that won't be as noticeable if they are a bit late. Another important note: If you're sending MIDI Time Code from a master computer to either another computer or some other device that must synchronize with it, you'll definitely want to put it as early as possible in the daisy chain. I would say, however, that if you can afford another computer, you can afford a larger MIDI interface.
If you need to synchronize multiple computers or sequencers, word clock is your best bet to tighten up timing. Choose a master device, and set all the others to slave to it. If your devices don't have word clock available on their interfaces, then MTC can do a pretty good job, with ¼-frame accuracy (to within about 8 ms). There's really only one major issue that comes up in this scenario, and that is when MIDI begins to drift apart from the audio as your song goes on. Make sure that your audio is synched to the MTC within your software, and you shouldn't have any trouble.
THE OLD SCHOOL
Certain vintage MIDI devices have significant inherent hardware latency. There is really only one solution for this: Record the audio, and nudge it back into place. The alternative would be to delay everything else to line up with your old synth — not practical. A similar problem exists with hardware samplers; this is not necessarily a hardware latency issue, rather a sample-editing problem. Highly transient samples (like hi-hats, for instance) must be edited such that their attack happens immediately when they're triggered. If there's even a little time gap at the beginning of the sample, the attack will be late.
If you take the time to make sure that your computer and interface are optimized as much as possible, to always be careful with your programming and to nudge audio into position, you'll be able to tighten up your timing and make your compositions sound cleaner and clearer. It's worth all the trouble!
HOW BAD CAN IT GET?
Each point on the chart represents a quarter note sent from Digidesign Pro Tools via an M-Audio MIDISport 2×2 interface to a Roland JP-8000 synth. The latency (in samples) of each note is shown in the scale on the left. The red line represents low-jitter timing when only one note is sent. “Flamming” refers to when two identical notes are sent too closely together, causing the synth to become confused. The blue line represents the inaccuracies caused by this.
THE WAVEFORM DOESN'T LIE
The “JP8000” track in brown shows low-jitter timing, and the “Flam” track in blue shows the inconsistent timing when both MIDI notes are transmitted simultaneously. To help solve this problem, try to send only as much data as is necessary. Most modern sequencers allow you to filter the types of data sent, so filter out any controllers you're not using. Thin any continuous-controller data as much as possible to reduce the amount of data sent. Also, make sure you don't have any unintentional flams in your programming.
NEW ISN'T ALWAYS BETTER
Theoretically, you can solve old-school hardware latency by using software synths. In reality, however, the latency can actually be worse. This screenshot shows a comparison in latency between an Alesis D4 drum module and the same hi-hat sound sampled into MOTU MachFive and NI Kompakt. The top track shows the MIDI note; the red track is the D4; the brown track is MachFive; the blue track is Kompakt; and the orange track is the same MIDI note sent to my JP-8000. The D4 clearly wins the latency battle, but the next graph shows another problem: jitter.
LAW OF AVERAGES
After statistically analyzing the timing of all 16 notes played by these instruments, it became clear that although the software samplers were later, they were consistently later. As a matter of fact, in terms of jitter, they were sample-accurate. The D4, on the other hand, was significantly inconsistent. The average latency was 33 samples, but event 2 was 64 samples late, and event 12 was only 11 samples late. Consistency is actually more important than lack of latency, because notes can be nudged back into position as long as they are consistently late. So use your software devices when you can to help eliminate jitter. Simply expand the view of your software with the MIDI track right next to the audio track to see how far to nudge the audio track.
| Want to use this article? Click here for options! |  |
