Minimising MIDI & Audio Timing Problems In Computer Sequencers

Logic's Track Playback Parameter box (left of screen) provides a delay option. Setting this to a negative value can improve timing on MIDI devices with a consistently slow response.

Although MIDI + Audio sequencing packages on both Mac and PC are becoming ever more powerful, 'the timing was tighter on my Atari' is still a common complaint. Paul White looks at ways of tightening it up, with additional PC information by Martin Walker.

Though computer‑based methods of music production are taken pretty much for granted these days, they're not without their problems. One which keeps coming back is the issue of timing, both with MIDI and audio. Modern Macs and PCs can run numerous audio tracks with real‑time effects alongside MIDI sequences, but many people complain that their audio tracks drift out of time with their MIDI notes or that their MIDI drum parts are noticeably out of time.

Taking MIDI first, it's easy to forget that MIDI is a serial system — it can only deal with one note or event at a time, so even if everything else acts instantaneously, there will always be a timing discrepancy of several milliseconds between the first and last note played in a big block chord, even if it's quantised. Usually the timing errors are small compared to the musical timing of even a good player, but if you have a composition comprising many MIDI tracks, all of which contain quantised notes at the start of a particular bar, the errors may become noticeable. Fortunately, there are strategies that can be used to improve matters.

Ports And Processors

Setting your monitor to 256 colours can help reduce the load on your computer's processor, improving timing.

The main complainants about MIDI timing are often people using pretty basic MIDI interfaces with only one MIDI Out. If the interface is part of a cheap PC soundcard, it might not do justice even to the finite speed of MIDI. If you use such a card and you're having trouble, check whether newer drivers are available, as these can often make a big difference.

MIDI is a bit like road traffic in that the more cars (MIDI data bytes) you have, the more likely you are to end up with a traffic jam. The better MIDI sequencers tend to give priority to MIDI note data above controller data to try to prevent this happening (a bit like using bus lanes?), but there must eventually come a point where timing suffers because of the sheer volume of MIDI data being transmitted. The obvious solution is to use a multi‑lane road — in MIDI parlance, either a multi‑port MIDI interface or several different soundcards, each with its own MIDI port.

Each of the ports on a multi‑port (not multi‑Thru!) interface has the same timing restrictions as a single MIDI port, but the overall amount of data that can be sent to the interface is restricted only by the speed of the communications link between it and the computer. It makes sense therefore to connect drum machines and other instruments that require a high timing priority to MIDI ports of their own. If you use multitimbral synths, try to reserve a separate port for each one, even though you may not be using all 16 channels.

Even this system isn't perfect, as the data link between the computer and interface can choke up when all the ports are busy, particularly if you have an interface with eight or more ports or if you tend to use a lot of continuous controller data. Some of the newer Emagic and MOTU interfaces get around this limitation by sending the MIDI information to the interface a short while before it is needed where it is held in a memory buffer. At the appropriate time, the data is clocked out of all ports simultaneously with the best resolution MIDI has to offer, regardless of traffic conditions on the computer‑to‑interface connection.

Users of older ('pre‑blue') non‑USB Macs may also find it advantageous to use two MIDI multi‑port interfaces, one connected to the printer port and the other to the modem port, so as to spread the load. Some PC users have reported problems when using hardware dongles on the same port as a MIDI interface, so it's worth checking with the relevant manufacturers before purchasing an interface to see if they are aware of any known incompatibilities.

Both MIDI and audio timing can be optimised by ensuring that your computer isn't doing any unnecessary tasks in the background. Scrolling screen displays usually take up more processing power than ones that jump when the cursor gets to the end of the screen, so try turning off scrolling, or zoom in so you can see the entire song in a single screen, if you think you're pushing your computer's capabilities. Mac users should also consider using Extensions Manager to disable any System extension that isn't needed for music, and screen‑savers are definitely something to avoid. Limiting your monitor to 256 colours can also reduce the processing burden.

Sequence Squeezing

Cubase VST's Priority setting, in the Audio System Setup dialogue, can be tweaked to suit the extent to which you're working with MIDI data or audio.

As well as general tweaks to your connections and system setup, there are various things you can do to the MIDI sequence data itself to improve timing. Rule number one must be to switch off any type of MIDI message you're not using. Disable MIDI Clock output and MIDI Machine Control (MMC) if you are not actually using them, and if the track you're recording doesn't require aftertouch switch it off at the keyboard — otherwise you'll clog up your MIDI data stream with irrelevant events that just slow the whole system down. Similarly, if you're using a MIDI guitar controller and the track doesn't need pitch‑bend, filter it out or switch to chromatic mode (beware of MIDI guitar systems that still send redundant pitch‑bend messages in chromatic mode — look in your Event Editor to select and delete unwanted pitch‑bend information if you don't have the option of filtering it out during recording). For every note you play, you may well be generating 10 or more unnecessary continuous controller messages, so this source of timing problems should not be neglected.

Having economised on your data stream, there are other techniques you can use to improve timing further. All MIDI instruments take a short time to respond to incoming MIDI data, and this can exaggerate any MIDI data delays that occur normally. If you have an instrument that you know is relatively slow, therefore, try applying a negative delay to the track (Logic users do this in the track Playback Parameter box, while Cubase users need to visit the Inspector) so that the MIDI data is sent a few milliseconds before the beat. This will compensate for the slow response of the synth.

Moving some of your MIDI notes slightly ahead of the beat can also improve the timing of other notes, as it avoids having too many notes trying to get out at exactly the same time. It's often worth doing this with slow‑attack sounds such as strings — it's possible to advance most slow string or pad sounds by several milliseconds before you can hear any difference at all in timing. Using the same reasoning, you may also find it better not to quantise tracks that use slow attack sounds, as this helps spread out the notes. Indeed, it's always best to avoid having too many quantised notes falling at the same time, so if you can leave something unquantised, so much the better.

Back in my old Atari days, I was told that drums and other parts with critical timing should be recorded on the lowest numbered MIDI channels, as these had timing priority. Today's sequencers have movable tracks, but it's still likely that data will be processed in order of MIDI channel, so it's a good idea to put all your timing‑critical stuff on the first few channels. Of course, this begs the question of why GM drum kits were assigned to channel 10 — answers on a postcard please! It's not impossible that the designer of your sequencer has given MIDI channel 10 timing priority rather than channel 1, but as nobody ever tells us these things it's usually a case of trying things out to see what works best.

Audio Timing

Most people can get by with the resolution of MIDI, but audio that refuses to stay in time with MIDI is extremely vexing to say the least. A delayed monitor signal (latency) is something most computer users have to accept while recording (this can be got around by monitoring the input signal via a hardware mixer), but in a properly designed system the latency will at least be consistent. However, once the audio is on your computer's hard drive, its timing may still wander around to a noticable degree if your computer is short of RAM, or if the software drivers are not up to date. This latter consideration is important as a poorly written driver may allow the playback latency to vary, and that will have the effect of making the audio seem out of time. You may also have to wade through pages of driver settings, twiddling the amount of RAM buffering and playback delay settings to get your system behaving properly. Thankfully, many soundcard manufacturers provide recommendations for setting up various MIDI + Audio sequencer packages with their products, which makes things a bit less hit‑and‑miss. Even so, there may still be occasions when the audio timing isn't tight enough.

Before you panic, one thing to check is that you're not asking the audio to start playing on the first beat of a sequence. When you press start on the sequencer, a certain amount of behind‑the‑scenes shuffling and buffer‑filling goes on before the audio can start to play, so if your audio comes in on beat one of the song, try placing a couple of empty bars after the count‑in and before the song start to give the computer time to get its act together.

When audio is recorded into a computer, the audio data is usually clocked by a crystal clock on the soundcard, and though crystal clocks are very stable, they don't all run at exactly the same speed as each other. This means that if you have a system with two or more soundcards, you have to be careful when recording via one soundcard and playing back via another as the playback speed may be slightly different. Although both soundcards may nominally be clocking data in and out at exactly 44.1kHz, for example, in fact they will have fractionally different sampling rates because they have fractionally different clock speeds. If each track is replayed using the same card and clock speed as when it was recorded, there should be no problem. However, things can still go wrong in a system where you want to sync audio to an external digital timing clock. Because the external clock may not run at exactly the same speed as the clocks on your soundcards, the playback speed of any tracks originally recorded using the soundcards' internal clocks may again drift slightly, and in the case of long audio tracks, the further you get into the track, the greater the drift. If both soundcards are the same model, from the same manufacturer, then the drift may well be rather smaller than otherwise, but it will probably still exist to some degree. The lesson here is that if you intend to sync all your cards on playback, sync them while you're recording too. It's also unwise to split stereo signals between two cards as even the slightest timing difference will cause an unpleasant flanging effect. Where possible, record stereo as a stereo audio file — that way the two halves can't drift.

A subjectively similar thing happens when your audio is stable but you decide to sync the sequencer to an outside source, such as a tape recorder or other device. If the master device runs a little slow, your MIDI sequence tempo will drop to match it, but the audio may carry on at its original rate, causing the MIDI and audio to drift apart. The better sequencers have something called continuous audio resync that varies the audio speed to match that of the timecode coming from the master machine, but not all have it.

If, despite your best endeavours, audio timing stability is still inadequate, one of the most effective workarounds is to divide long audio tracks into sections each just a few bars long. Each section will now trigger independently so although there may still be a small amount of drift within each section, the effect won't be cumulative. This doesn't always provide a complete cure, but in most cases it's enough to get by. The real problems start when your drum parts start drifting, as drum timing is extremely critical.

Cubase VST provides a priority setting in its system setup page. This defaults to 'normal', which gives equal priority to both audio and MIDI, but if you work mainly with audio, you can change this to High or Highest, which causes audio data to be given processing priority. This may give you better audio performance when using lots of plug‑in EQ and effects, although MIDI timing may suffer. If on the other hand you work mainly with MIDI, reducing the audio priority setting to low will ensure that MIDI signals get processed first.

It is also important with VST to have the correct setting for system pre‑roll in the synchronisation menu. Normally this should be set to the same value as the soundcard latency, as reported in the audio setup window. This allows the MIDI data to be prepared in advance of the audio data, so that the MIDI timing can be more accurate.

One of the first lessons that sampler users learn is that, when they want to use drum loops, the last thing they should do is set the sample itself to loop, then try to match the sequencer tempo to the loop. Even if you could match it, the propensity for drifting apart always remains. Instead, the sampler should be set to play the loop just once when triggered, with a new trigger note added to the sequence every bar, two bars or whatever the loop length is. As in the previous example, this means that even if there is any small amount of drift during the period of the loop, the next time the loop is triggered it will at least start on time.

When it comes to creating audio loops within your sequencer, much depends on how slick your sequencer is at retriggering the same piece of audio. Logic is pretty good at this, but if you find that there's a slight timing discrepancy as the sequencer jumps back to the start of the audio segment, you may be able to make a small tempo change (a few hundredths of a bpm) to compensate. In the event that you can't find a satisfactory cure, perhaps going back to entrusting your drum loops to an external sampler would be a way out of trouble.

And Finally

Most of the solutions to timing problems are down to common sense, once you've realised what's causing them in the first place. The bottom line is that, nowadays, we expect rather a lot of our computers. Not only do we run MIDI and audio, we also expect computers to be able to deal with mixing, EQ, VST real‑time effects and even virtual synthesis. All this takes some of the computer's time, so unless you have the latest and greatest in computer technology you may find that your problems are simply down to having an underpowered system. Software manufacturers don't help here, as the minimum spec they quote on the box is usually hopelessly inadequate, and in any event that specification probably assumes that your computer is doing nothing more than running a few audio tracks plus MIDI. Load in a few plug‑ins or virtual synths and the processing demands go up enormously.

Even if your computer is a Pentium III or a Mac G3/G4, you'll need to ensure you have plenty of memory — again ideally at least double the minimum specified — and you'll probably need to spend some time trawling the web to find the latest drivers and setup info for your hardware. Unfortunately, memory prices have gone up enormously since the tragic Taiwan earthquake. After the software support help lines (yes, I know they're very busy), Internet user groups are probably the best place to start, and if you're a PC user, you'll find thousands of words of PC‑related FAQs in the SOS forum on our web site, many of which relate to timing problems. If you're having a problem, the chances are somebody else is too.