MIDI Zero Velocity Note Off Explained

In the original MIDI 1.0 specification published in 1983, a Note On message sent with a velocity value of zero is officially interpreted as a Note Off command. This architectural design choice served primarily as a bandwidth-saving technique for hardware communicating over slow serial connections. By allowing instruments to turn off sounding notes without switching status bytes, the specification enabled the use of "Running Status," significantly reducing data overhead during dense musical performances.

Standard Note On vs. Note Off

In the MIDI protocol, musical events are transmitted as sequences of 8-bit bytes. Playing and releasing a key traditionally requires two distinct channel voice messages:

• Note On (0x9n): Followed by two data bytes representing Note Number (0–127) and Velocity (1–127), indicating how hard the key was struck.
• Note Off (0x8n): Followed by two data bytes representing Note Number (0–127) and Release Velocity (0–127), indicating how quickly the key was released.

Under this standard approach, alternating between playing notes and releasing notes requires the transmitter to send a three-byte message for the strike (0x9n, note, velocity) and another three-byte message for the release (0x8n, note, release velocity), totaling six bytes per played note.

The Running Status Optimization

MIDI 1.0 operates over a 31.25 kbaud serial connection, which allows roughly 1,000 to 1,500 messages per second. In complex, polyphonic sequences, bandwidth saturation could cause audible timing jitter and latency.

To mitigate this, the MIDI standard introduced "Running Status." When consecutive messages share the exact same status byte, the sender can omit the status byte entirely, transmitting only the subsequent data bytes.

If a performance alternated strictly between traditional Note On (0x9n) and Note Off (0x8n), Running Status could rarely be used because the status byte changed continuously. By defining a Note On command with a velocity of zero (0x00) as an explicit release command, both the attack and release of notes could remain entirely under the 0x9n status byte.

Bandwidth Savings in Practice

When leveraging zero-velocity Note Off with Running Status, the communication flow operates as follows:

1. First Note Strike: [0x90] [Note Number] [Velocity > 0] (3 bytes sent; establishes Running Status)
2. First Note Release: [Note Number] [0x00] (Only 2 bytes sent)
3. Second Note Strike: [Note Number] [Velocity > 0] (Only 2 bytes sent)
4. Second Note Release: [Note Number] [0x00] (Only 2 bytes sent)

After the initial status byte is declared, every subsequent note-on and note-off event requires only two bytes instead of three. This yields an approximate 33% reduction in data transmission for note events, keeping the MIDI pipeline responsive.

The Trade-Off: Release Velocity

The primary drawback of this implementation is the loss of release velocity. While standard Note Off (0x8n) includes a dedicated velocity byte allowing sound engines to modulate release parameters—such as the decay rate of a physical string model or envelope release time—a Note On message with zero velocity fixes that parameter to zero.

Because very few synthesizers and keyboard controllers in the 1980s supported mechanical release velocity sensors, the MIDI Manufacturers Association prioritized data efficiency over release sensitivity. As a result, almost all modern DAWs, sequencers, and MIDI controllers treat 0x8n messages and 0x9n messages with a velocity of zero interchangeably.