Running Status

At the end of the previous chapter we met a Note On message with a velocity of zero, and I promised to explain why anyone would stop a note with a message whose name says the opposite. The answer is a small trick from the early days of MIDI called running status. It takes a minute to understand, and once you have it, a few other oddities of the protocol fall into place as well.

A cable with very little room

MIDI was designed in 1982 for a cable that carries 31,250 bits per second. A byte takes ten of those bits on the wire, so a three-byte Note On needs roughly one millisecond. That does not sound like much, until you remember what a performance actually produces: chords of six notes, each with a Note On and a Note Off, a mod wheel sending a Control Change for every tiny movement, a pitch bend doing the same, all on top of each other. The cable fills up quickly, and when it does, notes arrive late. A delay of a few milliseconds is audible to a drummer.

The designers of MIDI looked for anything they could leave out, and they found the status byte.

Leaving out what the receiver already knows

Think about what happens when you play a chord. The keyboard sends three Note On messages on the same channel:

0x90 0x3C 0x64
0x90 0x40 0x64
0x90 0x43 0x64

The status byte is the same three times. The receiver, having seen the first one, already knows that Note On messages on channel 1 are coming. So the rule is: a sender may leave out the status byte, as long as it is the same as the last one it sent. The receiver remembers the last status byte and applies it to any data bytes that arrive without one:

0x90 0x3C 0x64
     0x40 0x64
     0x43 0x64

Three messages, seven bytes instead of nine. On a stream of controller movements the saving is a full third, because a stream of Control Change messages from one knob has the same status byte for as long as the knob moves.

The same three notes with and without running status. A status byte in parentheses is not sent; the receiver supplies it.

This is possible only because of the rule from the Bits & Bytes chapter: a status byte always has its msb set and a data byte never does. When the receiver sees a byte below 0x80 where a status byte would normally be, it does not need to guess. It knows it is looking at data and that the status is running from before.

And now the velocity-zero note

Here is where the trick pays off. A keyboard player plays a note and releases it. By the book, that is a Note On with status 0x90 followed by a Note Off with status 0x80. The status changes, so it has to be sent in full, and running status gives nothing for a melody where every note is followed by its own release.

Unless the release is sent as a Note On with velocity zero. Then the status byte stays 0x90 throughout, and a whole melody can run without a single repeated status byte:

0x90 0x3C 0x64    note on, C4
     0x3C 0x00    the same note released
     0x3E 0x64    note on, D4
     0x3E 0x00    released

That is the reason the specification says that Note On with velocity zero must be treated as Note Off. It was never meant as a riddle; it is what running status looks like in the hands of a keyboard that wants to save bytes. Many instruments send their releases this way to this day, and any device that receives notes has to accept it.

What breaks the run

Running status lasts as long as the status byte would be the same. It ends the moment a different one is needed: a different message type, or the same type on a different channel, because the channel is part of the status byte. The sender then sends the new status byte in full, and that one becomes the running status for whatever follows.

It applies to channel messages only, the ones from the table in the previous chapter. System messages such as Song Position or a SysEx message end the run; after one of them the next channel message starts with a full status byte again.

The System Real-Time messages are the exception that proves how the whole scheme hangs together. A Clock byte, 0xF8, may land anywhere, even between the two data bytes of a note, and it does not disturb the running status. The receiver handles the clock and carries on where it was:

0x90 0x3C 0x64
0xF8              a clock tick, dealt with and forgotten
     0x3E 0x64    still a Note On on channel 1

A single-byte real-time message cannot be mistaken for anything else, so it costs nothing to let it through.

Running status and the Electra One

You will not see running status in the MIDI Console, and it is worth understanding why. The console shows what reaches your computer over USB, and USB MIDI packs every message into a small packet that always carries its status. Running status is a feature of the classic five-pin sockets, where the bytes really do travel one after another down a slow wire. On USB there is nothing to save.

On the controller's MIDI IO sockets the situation is different, and the Electra One handles both directions. Everything that arrives there is understood with or without status bytes, so a synthesizer that saves bytes the old way works without any setting. For what the controller sends, running status is switched on per device in the preset editor. Leave it off unless an instrument's manual asks for it or the stream is very dense; and even when it is on, the Electra One repeats the status byte ten times a second, so an instrument switched on in the middle of a stream picks the run up straight away.

The place you will meet running status, then, is not the console but a manual, a MIDI monitor attached to a five-pin cable, or a SysEx parser of your own. When you see data bytes with no status byte in front of them, you now know exactly what you are looking at.

What comes next

A full third of a message is a good saving, and it buys MIDI breathing room. The next chapter looks at the opposite problem: a message that is too small. A Control Change carries 128 values, and for a filter cutoff that is not enough.