RUNNING STATUS IS ONE OF THOSE GREY AREAS OF MIDI THAT IS ONLY EVER DISCUSSED WHEN IT BRINGS PROBLEMS. BUT IT'S ACTUALLY A USEFUL METHOD OF OPTIMISING MIDI'S TIMING ACCURACY.

THE SPEED OF MIDI, as the TV adverts might say, is fast - but not that fast. The fact that MIDI data travels at a speed of 31.25Kbits per second isn't really very interesting to most musicians whose main interests lie in music. The important fact is that it takes just under one millisecond for a key press on a keyboard to be transmitted along a MIDI cable - and in most situations, this is a musically insignificant period of time.

But let's take a closer look at what's actually going on. Each time that you play a note, a MIDI message for a note on event is transmitted from the MIDI Out port of the originating instrument. This message consists of three bytes; the first is a Status byte and identifies the message as being a MIDI note on a specific MIDI channel; the second and third are Data bytes and give the note value (pitch) and velocity respectively. Each byte takes 0.32ms to transmit so the entire message takes 0.96ms - a little less than 1ms.

MIDI is a serial protocol. This means that only one byte is transmitted at a time (a parallel protocol permits the simultaneous transmission of several bytes). When a chord is played, therefore, what you actually hear is a fast arpeggio of the notes in the chord. If you want to check this, try the following experiment; Set up a drum machine or sampler in Omni On mode and check the MIDI note value of a short percussive sound like a closed hi-hat - say, C3. Record a C3 on the first beat of the first bar on track one of your sequencer and assign it to MIDI channel one. Now copy this to the same position of tracks 2 to 15, adding one to the MIDI channel each time (if your sequencer has less than 16 tracks, you can use copy and then merge to achieve the same result). You should end up with 16 notes, each at the start of the bar, and each on a different MIDI channel. When you run the sequencer, you will hear a flammed hi-hat. Now set the drum machine to Omni Off and assign the hi-hat sound to two different pads, one receiving on MIDI channel 1 and the other on MIDI channel 16. Play back the sequencer again. This time you should hear two distinct notes rather than a flam. All 16 notes are playing, but you're only hearing the first and last, with a 13.44ms gap in between. The reason you've probably never noticed this before is that the gaps are usually covered by the dynamic of the sound.

So how much of an effect does all this have on your music? The answer depends upon how much you rely on quantisation; it isn't inconceivable that you'd want a bass drum, closed hi-hat, crash, bass synth, eight-note piano chord and eight-note pad chord to occur at the same point in a song. If you only quantise the drums and bass, the piano and pad chords will be spread over a short period of time lessening the problem. If you quantise everything, however, then you get 20 notes supposedly occurring at the same time - but actually spread over 19.2ms. Whether you hear this will depend on how your sequencer handles its data. It may give priority to data on the lower numbered tracks or MIDI channels, in which case this is where the bass, drums and any other percussive instruments should be recorded. However, life can get difficult if you have to think about your music in these terms.

But note information is not the worst offender when it comes to causing delays. Any continuous MIDI controller - like volume or mod wheel - transmits 128 sets of three bytes each time you move from one extreme to the other. Channel pressure (aftertouch) is equally guilty and as for pitchbend wheel, the number of sets of three bytes transmitted will depend on the pitch wheel sensitivity of the keyboard - 128, 256 or 512 are typical values.

RUNNING STATUS

THERE IS, WITHIN the MIDI specification, a process defined which will reduce the amount of MIDI data required to handle all these tasks. This is called Running Status and works like this: imagine you have a train pulling two carriages and you wish to increase the load. You could use another train with two more carriages but that would be wasteful. Why not just hook the extra carriages onto the first two to give one train pulling four carriages. The train in our case is a status byte and the carriages are the data bytes. If the status byte doesn't change from one MIDI event to the next, it can be left off. This will just leave the data bytes.

Let's look at an example:

91 3C 75
91 40 77
91 43 72
91 3C 00
91 40 00
91 43 00

This represents: MIDI channel 2, note on C3, velocity 117; MIDI channel 2, note on E3, velocity 119, MIDI channel 2, note on G3, velocity 114; MIDI channel 2, note on C3, velocity 0, MIDI channel 2, note on E3, velocity 0, MIDI channel 2, note on G3, velocity 0.

More understandably this represents a C major chord being played on MIDI channel two and followed by the same notes being released. The release is indicated by a velocity of zero. The whole string takes 17.28ms to transmit.

Now look at the same string under running status:

91 3C 75
40 77
43 72
3C 00
40 00
43 00

This represents: MIDI channel 2, note on C3, velocity 117; note on E3, velocity 119; note on G3, velocity 114; note on C3, velocity 0; note on E3, velocity 0; note on G3, velocity 0.

The time taken for transmission here is 12.48ms, a saving of nearly 5ms.

Any voice or mode message - one with a MIDI channel included. So taking the previous example of a pitchbend wheel sending 256 sets of three bytes for a full movement, we get the following:

"THE RESULT OF LOST MIDI BYTES CAN BE DECIDEDLY GHOSTLY - THE STAFF OF ONE STUDIO SMITTEN BY THIS PROBLEM BELIEVED THE PLACE WAS HAUNTED!"

Without running status:

256 x 3 x 0.96 = 737.28ms

With running status:

(1 + 256 x 2) x 0.96 = 492.48ms.

We've achieved a saving of nearly a quarter of a second. And a quarter of a second is enough to cause an audible timing glitch if no data thinning or shuffling is carried out by the sequencer. The only care that needs to be taken with this system concerns notes off. Using a note on with a velocity of zero is one way of handling notes off, the other is to use a status byte of 81 (hex), but in this case running status can't be used. This is used by keyboards which can generate a release velocity dependent on how fast you release the key.

GET TECH

ALL MIDI DEVICES capable of receiving MIDI data have to be capable of recognising and handling running status. However, not all transmitting devices have to be able to send data under it.

A receiving device will probably have a one-byte buffer specifically for the current status byte. This buffer should be cleared at power up and when any MIDI system exclusive or common data is received. This buffer would be used for MIDI data dumping or sample transfers, MIDI real-time messages (such as MIDI clock and start, stop and continue commands) have no effect on the contents of the buffer.

Another technical consideration is that if the running status buffer is empty, any data bytes will be ignored. This could occur if you turn on a keyboard first, which is sending MIDI data under running status, send a note on and then turn on a connected synth. The running status buffer will be empty and any ensuing notes on sent from the keyboard will be in the form of two data bytes only. In other words, you won't hear anything. If this happens, the easiest way to rectify the situation is to send a different MIDI event by moving the pitchbend or mod wheels - this changes the buffer. A note on will then change the buffer again and restore the functioning of the system. The way to avoid this situation is to always turn on the master last.

The danger of abbreviating MIDI messages in this way is that strange things can happen if you lose a data byte? In theory this should never happen, but let's consider for a moment what the audible result of a lost byte on our previous example would be:

91 3C 75
40 77
43 72
3C 00
40 00
43 00

Again this represents: note on C3, velocity 117; note on E3, velocity 119; note on G3, velocity 114, note on C3, velocity 0; note on E3, velocity 0; note on G3, velocity 0.

Now let's "lose" the data byte for the C3 note on (3C). We end up with this:

91 75
40 77
43 72
3C 00
40 00
43 00

Which translates to: note on A7, velocity 64; note on B7, velocity 67; note on F#7, velocity 60; followed by two more notes which are too low to be heard.

The result is decidedly ghostly - instead of mid-keyboard notes with high velocity, you get high notes with mid velocity. The staff of one studio smitten by this problem believed the place was haunted! To avoid such problems it's a good idea for most MIDI devices transmitting under running status to send a status byte after every ten or so MIDI messages. Some do, some don't.

Another problem you may meet is the non-implementation of running status in certain MIDI devices. This includes the early Yamaha DX7, Ensoniq Mirage and Sequential Circuits Prophet t8. This is because running status was not initially included in the MIDI spec.

The advantage of working with running status is that the system displays better timing characteristics than are otherwise possible. Some sequencers are now offering you the option of transmitting under running status. And unless one of your MIDI devices doesn't support the protocol, you would be well advised to take advantage of it. Just a final word of warning: be aware that no sound when hitting your keyboard or the expected presence of gremlins inside your computer will probably be down to your status doing a runner.