Solving MIDI Timing Problems

 By Martin Walker

Early notes, late notes, stacked notes... There's a range of problems that could stem from MIDI timing issues - but fortunately we have solutions to offer.

Here, at maximum zoom, with the Ruler set to Seconds (one horizontal division on the grid measures 10ms), you can see the MIDI timing results for my PC. The top (yellow) notes are the original hand-drawn 16th notes; the six sets of purple notes show three passes using the Maple virtual MIDI device, first without and then with system timestamp enabled; these were followed by six sets of green notes for the same options, using my Emu 1820M MIDI ports; and a final set of six blue notes for the Emu using emulated DirectMusic ports. As you can see, on my PC ticking the 'Use system timestamp' box always results in much tighter timing, and the tightest timing is given by Windows MIDI drivers with this option (light green).Most people simply install Cubase and get on with recording and playing back MIDI and audio tracks with no problems. However, a few — particularly PC users — experience annoying MIDI issues, such as erratic timing, events that are consistently recorded too early or too late and doubling (or even tripling) of note data. In extreme cases no data may be recorded at all, or every single MIDI event recorded during a lengthy take may end up appearing at the start of the Cubase part. People who are affected by such issues obviously search out possible cures, but even Cubase users who don't have specific problems should really check the various options to ensure they achieve the tightest possible MIDI timing. Let's find out how.

Background

A significant proportion of Cubase MIDI problems arrived when Steinberg launched their Midex range of interfaces, because they used DirectMusic drivers instead of the more typical Windows MIDI version, largely because this format offered a more precise timestamp, and therefore the likelihood of tighter MIDI timing. Unfortunately, not many other MIDI interfaces had DirectMusic drivers, and in their absence Windows creates 'emulated' DirectMusic drivers with much higher latency and generally lower performance.

Cubase might therefore find Windows MIDI drivers, true DirectMusic drivers, and emulated DirectMusic drivers, and unless all but the most appropriate one is hidden you can end up with two or even three sets of MIDI inputs and outputs, leading to doubled or tripled sets of data during recording or playback. If you end up using emulated drivers your data could be recorded early or late, piled up at the start of a Part, or not recorded at all.

Steinberg's answer was a filter that guessed at the most appropriate MIDI drivers and hid all the others, but the first filter version didn't always choose correctly, and many musicians had to 'unhide' the filtered versions (by dragging the file named 'ignoreportfilter' from the MIDI Port Enabler folder into the main Cubase folder), and then manually configuring their MIDI ports.

However, from Cubase SX/SL and Nuendo versions 3.0.1 onwards, Steinberg introduced a more refined filtering regime: if true DirectMusic drivers are detected, they are used and if not, Windows MIDI drivers are used instead, while emulated DirectMusic ports are never used by default. The filter hides all the unused MIDI ports, and in the majority of systems it works really well.

Windows Timers

A second set of MIDI timing problems arose due to PCs providing two different timers. Older versions of Windows, older MIDI interfaces, the VST and ASIO specifications, plus Cubase/Nuendo (and many other sequencers) normally rely on Windows' TGT (timeGetTime) timer, which apparently has a resolution of one millisecond. Meanwhile, some newer audio and MIDI interfaces, such as those with true DirectMusic drivers, plus some other sequencers, use the QPC (QueryPerformanceCounter) timer, which can theoretically be more precise (with a timestamp based on units of 0.1ms).

While a few motherboards keep both clocks in perfect sync, on many systems these two clocks slowly drift apart, so if Cubase is following the TGT timer and your MIDI interface is timestamping data according to the QPC timer, your MIDI can get seriously out of kilter. The answer, which Steinberg first implemented in Nuendo 2 and Cubase SX 2.3, is a software switch labelled 'Use system timestamp' which, when ticked, instructs these sequencers to follow the QPC timer instead of the TGT one.

By the way, this is a Windows rather than a Cubase-specific issue. Cakewalk's Sonar, to give another sequencer example, has a parameter named 'IgnoreMidiInTimeStamps' in its TTSEQ.ini initialisation file, with a default value of zero that you can change to '1' if your MIDI data is being recorded at the wrong time or it is drifting.

Up until Cubase SE/SL/SX 3.0.1 and Nuendo 3.0.1, Steinberg's 'Use system timestamp' option only affected DirectMusic drivers, so if you suffered from strange timing anomalies when using Windows MIDI drivers, and your interface didn't provide bona fide DirectMusic drivers (few do even now), the only solution was to enable the emulated DirectMusic ports, by bypassing Steinberg's 'ignoreportfilter', and try those instead, with the timestamp box ticked.

However, from Cubase SE3, SL and SX 3.1 and Nuendo 3.1 onwards, a separate 'Use system timestamp' option has been available in the Windows MIDI page, so even in multi-interface systems using both DirectMusic and Windows MIDI drivers you can cure timing problems individually. You can find these timestamp tick-boxes by opening the Device Setup window from the Devices menu — there's one in the DirectMusic page and a second in the Windows MIDI page of the MIDI section.

You can also find out which clock is used by a MIDI interface that has non-DIrectMusic drivers (the majority), by running Jay Levitt's handy MIDITime utility (www.jay.fm/miditime/). You connect your chosen interface In and Out via a MIDI loopback cable and then run the utility, which simply sends MIDI data round the loop, compares its timestamping against both system clocks, and tells you whether your system needs to have the 'Use system timestamp' box ticked.

Live MIDI Buffering Jitter

Many musicians find it difficult to get their heads around the concept of live MIDI buffering jitter, so here are the results of some practical tests. The top two yellow tracks show the original hand-drawn MIDI notes, and the very tight timing after looping them back via the Maple Virtual MIDI Cable. The output of this second track is routed to the LM7 drum synth, triggering a short clave sound, and what gets recorded is shown in the uppermost audio track. Beneath this are audio loopback captures of what you actually hear from the soft synth in real time, with increasing audio-interface buffer sizes. Even at 10ms latency you should be able to spot slight differences in spacing between the notes, while at higher buffer sizes the effects are greatly magnified, and notes will begin to emerge in 'clumps'. I've also shown two passes for the 50ms and 100ms buffer sizes, to show how this clumping will vary depending when the notes are played, compared with the creation of each new interface buffer.If you're struggling with jittery MIDI timing problems when playing soft synths 'live', it may be due to an entirely separate issue that affects quite a few sequencers on both Mac and PC platforms, including Cubase, Logic, Reaper and Sonar, amongst others. Your performance will be captured exactly as you played it, and will also play back exactly the same, but since you hear jittery timing when actually playing, it makes it more difficult to play consistently in the first place.

This (as I explained in detail in SOS September and October 2002, in 'The Truth About Latency') is because most sequencers effectively quantise incoming MIDI data before sending it 'live' to a soft synth or sampler. The synth's output is calculated for each audio buffer and then sent to your audio interface to be heard, and the most common way of doing this is to process all relevant MIDI data (both already recorded in the track, and any 'live' data that you're currently playing) before starting to process the next audio buffer.

Unfortunately, most sequencers choose not to calculate any offsets within the next buffer relating to 'live' MIDI data — they just quantise them all to the nearest buffer boundary, and rely on the buffers being short enough to mask unwanted rhythmic artifacts. The main reason they do this is to keep every note's MIDI latency as low as possible, but at the expense of extra jitter.

For instance, if you play regular 16th notes at 120bpm, each note will occur at an interval of 125ms, but when a soft synth is played 'live' through an audio interface with a buffer size of 5ms you'll perhaps hear them with spacings such as 125ms, 125ms, 125ms, 130ms, 120ms, 130ms, 125ms and so on, where occasional notes get shoved into adjacent buffers. For most people this is still scarcely audible, but if you raise the buffer size to 20ms then you might hear a string of 'live' notes emerging with spacings of 120ms, 120ms, 120ms, 140ms, 120ms, 120ms, 140ms and so on: the 'granularity' has increased.

There's a very easy way to find out whether your sequencer suffers from live MIDI buffering jitter. Simply increase the audio interface buffer size to the maximum setting available and play in some fast, regular, repeated notes. Most people should be able to hear the difference once the buffer size has increased to 1024 samples (12ms at 44.1kHz) and if you increase it to 4096 or beyond you'll hear your live notes start to emerge in irregular clumps, despite being recorded perfectly (see the screenshot below for more extreme examples).

Conversely, there's also a very easy way to minimise these 'live' timing jitter problems: always drop to a lower buffer size, of 6ms or less, when recording a 'live' soft-synth performance. Although the recorded data will be identical, you'll hear a more accurate live rendition of what you're playing.

The Real World

While I suspect that the majority of Cubase users don't have MIDI timing problems, those that do soon speak up, so you can find quite a few complaints on the Cubase forums about MIDI recordings where all the data ends up way ahead of the audio (sometimes by several beats) or way behind. The answer is nearly always to tick the relevant 'Use system timestamp' option, but you can't assume that this is always the best setting — it depends both on your PC's motherboard and the make and model of your MIDI interface (or your audio interface, if that provides the MIDI ports). It's quite possible for Cubase to work really well until you change your interface, whereupon your MIDI timing suddenly goes completely screwy.

Because the two PC clocks may gradually drift apart, if you have unsuitable settings you may find that Cubase starts off with very good MIDI timing, but gets gradually worse the longer it's running. During really long sessions, notes being recorded may eventually appear in the correct position in a part initially and then suddenly jump forwards or backwards in time. The longer your PC is powered up, the bigger these jumps become, but if you close down Cubase and then re-launch it immediately, the problem will disappear.

Such long-term drifts mean that many users rarely notice any problem until they are deep into a session, and then they panic, try the system timestamp option, and find it cures their immediate problem. However, since they don't know why this works and everything seems to be hunky dory the next time they launch Cubase, they are reluctant to leave the timestamp option ticked permanently. The problem is compounded by the fact that different MIDI interfaces may need a different setting, so if, for example, you use a couple of keyboards that have their own USB MIDI connections or several different MIDI interfaces to connect all your MIDI gear, you may enjoy excellent timing from one but poor timing from another one. With the correct combination of MIDI driver and timestamp setting your MIDI timing should always remain consistent.

I suffered recently from the exact problem I've just explained. For several months I'd been happily using a two-octave Evolution MK225C keyboard for MIDI editing, connected via its own USB port. However, when I wanted to record some new performances using my 88-key CME UF8, connected via the MIDI port of my Emu 1820M interface, all the recorded notes ended up piled up at the beginning of the part. As most people would, I just switched back to the MK225C to finish my work, but the next day I took some time to investigate further, only to find that the UF8 recorded notes perfectly. Then, when I attempted to use it to record some MIDI controller data, it once again all ended up at the beginning of the part. So I ticked the 'Use system timestamp' option and my timing problems immediately disappeared.

Testing The Options

If you want to find out once and for all which combination of settings provides the tightest timing for your particular motherboard timer and MIDI interface, you should ideally test all four possible combinations of tick-box and MIDI driver (Windows MIDI driver with and without system timestamp, and real or emulated DirectMusic driver with and without system timestamp).

Because even emulated DirectMusic drivers may benefit from the increased timing resolution of the QPC clock, you may, in some cases, end up with better timing using these than using real Windows MIDI drivers. If you're really determined to explore every possibility, you could also try combinations of Ins and Outs; a few musicians have even found that their best timing comes from using Windows MIDI for their MIDI Outs, but emulated DirectMusic for their MIDI Ins, for example.

To test the timing of any sequencer you just need to create a few bars filled with hand-drawn 16th notes, using the pencil tool (to provide a regular signal), and then route this to a MIDI output that you can connect back to the MIDI input of another track, so you can capture the combined latency and jitter of these MIDI ports.The test itself is easy, and is exactly the same for any sequencer. Start by creating a song running at 120bpm, and make sure Auto Quantise is disabled; create a MIDI part lasting several bars; and then use the pencil tool to fill it with continuous 16th notes. Route the output of this track to the MIDI Out to be tested. Next, create a second MIDI track and leave its output unconnected but route its input to the MIDI In to be tested. Finally, connect a MIDI cable between this MIDI output and input, then select the second track and record for several bars, so that the hand-drawn notes from the first track are passed through the MIDI output, then back through the MIDI input and recorded onto the second track.

Now you can zoom in on both tracks simultaneously, to see how far apart individual notes are on each. On the recorded track, the note starting positions may be consistently earlier or later than those of the hand-drawn notes (latency), but start-position timing is also likely to vary a little between notes (jitter). If you switch your Ruler readout to 'seconds' you'll be able to measure the timing difference for each note in milliseconds. Do this for a dozen or so notes and you'll have a good idea of both latency and jitter.

Try the same test several times, creating a new recorded track each time, and vary system settings, such as ticking the 'Use system timestamp' box. You'll soon see which setting gives the tightest results. You can also perform the same tests with first Windows MIDI and then DirectMusic drivers (real or emulated) to find out the tightest combination of settings for your system. As you can see from the screenshots earlier on in this article, ticking this option made a vast difference to absolute timing on my system, but little difference to jitter.

Fine Tuning

Another neat trick is to do the same tests after installing a Virtual MIDI Cable (VMC). This software utility adds virtual MIDI Inputs and Outputs to your system, so you can route MIDI data between different applications, but for our purposes it's perfect for sending MIDI data between the output and input of your sequencer without the added latency and jitter of your MIDI interface, so you can directly measure the MIDI timing of the sequencer. If you have timing issues, this technique will prove whether the problem is due to the interface or the sequencer. I installed Jeff Hurchalla's Maple Virtual MIDI Cable (www.hurchalla.com/Maple_driver.html). As I discovered, by testing it using Evert van der Poll's MIDItest utility (http://earthvegaconnection.com), the Maple cable imposes a negligible delay, of 0.01ms, and jitter too low to measure.

Using MIDItest you can soon get a good idea of the combined latency and jitter of an In and Out port on your MIDI interface alone. Here I've tested the Maple Virtual MIDI Cable device, proving it to have negligible latency of 0.01ms and jitter of 0.00ms — so you can effectively consider it a direct connection between MIDI In and Out, which makes it an ideal way to measure Cubase's own latency and jitter without the added effects of a hardware MIDI interface.My best setting was Windows MIDI with timestamp enabled, when I measured random note timing offsets between 0ms and 3ms with the Maple VMC loopback, and delays of between 1ms and 4ms with my Emu MIDI port loopback. In other words, the combination of my motherboard timers, Windows and Cubase alone produced a maximum jitter of 3ms, while the jitter was identical after adding my MIDI port, but with 1ms additional latency (which ties in with my MIDItest utility latency and jitter results). Bear in mind also that these results are the total of both MIDI input and output jitter: when using VST Instruments you'd only experience the input side, giving a likely MIDI jitter of possibly 1.5ms. Since a 16th note at 120bpm happens every 125ms, this is equivalent to a tiny 1.2 percent variation in 16th-note position — which sounds good to me!

With USB and Firewire audio interfaces that also provide MIDI ports, you are sending both audio and MIDI data down a single cable, so it's possible that MIDI timing may suffer when you're playing back or recording lots of simultaneous audio tracks. Even using a separate MIDI interface, or one that's part of a PCI or PCe audio interface, your MIDI timing many be compromised when your sequencer is being stressed in other ways. To test this out, add the 16th-note MIDI track and corresponding MIDI loopback recording track to an existing song that contains plenty of other audio and MIDI tracks. This way you can check your results under 'real-world' conditions. It may also be worth trying a change to the Audio Priority setting in the Advanced Options of Cubase Device Setup.

Sadly, these tweaks don't seem to work for everyone. There's a small minority of musicians that have tried all the options and still suffer from MIDI notes being placed too early in the part, sometimes by a large but consistent amount of several tens of milliseconds. Since such problems tend to happen with a particular combination of components, some people may have had no timing problems for years but then start to suffer when they move to a new PC. Sometimes changing the MIDI interface, or even the motherboard, will cure the problem, but if sequencer developers would offer us a MIDI offset parameter, a single tweak of this could remove recording and playback latency, leaving just the jitter component

Published December 2007