I'm looking for a general explanation of the fundamentals of the MIDI (Musical Instrument Digital Interface) protocol, including data packets and message structure. I'm particularly interested in how note on/off, control changes, and pitch bend messages are encoded. What steps occur when an instrument communicates with another device during a live performance? I'd appreciate your experiences and resource recommendations.
What is the MIDI protocol and how does it work in live performances?
👁️ 152 views💬 5 replies❤️ 0 likes
5 Replies
In live performances, MIDI sends three-byte messages—like 0x90 for Note On with note number and velocity, 0x80 for Note Off, control changes are sent with 0xB0 followed by parameter number and value, while Pitch Bend uses 0xE0 with LSB and MSB values to define the bend. My experience with USB keyboards and audio interfaces was that I just needed to plug in the cables, set the MIDI channel in the DAW to receive the messages, and then the transmission was instant with no noticeable delay.
MIDI is fundamentally a serial data protocol running at 31.25 kbaud, meaning each byte (8 bits) is sent within a single bit time slot. When an instrument on stage communicates with another device, a stream of status bytes and data bytes flows out of the "MIDI out" port. The three most common message types you’ll encounter are:
* **Note On/Off** – Status byte `0x9n` (n = channel number) is a Note On, `0x8n` is a Note Off. Data byte 1 = pitch (0–127, where C-4 = 60), data byte 2 = velocity (0–127). For example, `0x90 0x3C 0x7F` = channel 1, middle C played at full velocity.
* **Control Change (CC)** – Status byte `0xBn`. Data byte 1 = controller number (e.g., 7 = volume), data byte 2 = new value (0–127). This allows real-time control of things like sustain pedals or modulation wheels.
* **Pitch Bend** – Status byte `0xEn`. Pitch bend uses a 14-bit value split across two data bytes: LSB + MSB. 0x2000 (8192) is center, lower values bend down, higher values bend up. For instance, `0xE0 0x00 0x40` = full negative bend.
In live settings, these packets are synchronized using the "MIDI clock" signal, where every 24 pulses (PPQN) correspond to one quarter note. When an instrument is connected to a DAW or another synth on stage, the process follows these steps:
1. **Establishing the connection** – A physical (5-pin DIN) or USB-MIDI link is created between two devices. In USB-MIDI, the OS generates a "MIDI endpoint," and devices send packets through this endpoint.
2. **Channel and program setup** – Each device listens to one or more channels. To avoid "writing collisions" on stage, channel assignments (e.g., channel 2) are made when multiple instruments are playing on the same channel.
3. **Data flow** – As the instrument is played, note-on/off, CC, and pitch-bend messages are sent in real time. The DAW receives these messages and routes them to virtual instruments or external synths.
4. **Clock & Transport** – If tight synchronization is needed (e.g., for arpeggiators), "MIDI Clock" messages (0xFA start, 0xFC stop, 0xF8 tick) are sent. Devices sync their tempo and bar position to this signal.
For comparison, modern stages often use **OSC (Open Sound Control)**. OSC runs over UDP, bypassing the 8-bit/16-bit limitations of MIDI and offering much higher data resolution and hierarchical addressing (e.g., `/synth1/param/volume`). However, due to network latency, OSC isn’t ideal for tight timing in percussive or pitch-bend applications—MIDI’s deterministic 31.25 kbaud structure still wins for real-time, low-latency performance. In short, if you need rock-solid, low-latency timing, MIDI’s fixed timing and reliability beat OSC’s flexibility but network dependency.
For solid references, check out the **MIDI 1.0 Specification** PDF and *The MIDI Manual* by David Miles Huber. Also, grab **MIDI-OX**, a free tool for real-time packet analysis and troubleshooting. If you nail these basics, you’ll debug stage issues in no time. Honestly, just experiment with different channels and CC mappings—trial and error will get you the smoothest workflow.
Dude, MIDI actually encodes note on/off as 0x90/0x80, control change as 0xB0, and pitch-bend as 0xE0 + 14-bit data—all in an 8-bit packet (status + two data bytes). On stage, the instrument sends these packets over a cable to the receiver with the same channel and program change settings, and boom—there’s your “beep-boop.”
Honestly, my first try had the cable plugged in backward, and I was still getting that “playing in the mud” sound. But after a couple of tries, the 🎹➡️🎛️ messages started flowing smoothly! 🎉
In a live performance, the typical MIDI workflow starts with the instrument generating messages (a keyboard, controller, or module) and sending them via a 5-pin cable or USB to a receiver (synthesizer, DAW, or interface). Each message consists of bytes: the first byte is the "status" (0x8n for Note Off, 0x9n for Note On, 0xBn for Control Change, 0xEn for Pitch Bend), where "n" is the channel number (0–15). The next two bytes are the data; for Note On/Off, these are the note (0–127) and velocity (0–127). In a Control Change, the first data byte is the controller number (CC #) and the second is its value (0–127). Pitch Bend uses 14 bits, so the two data bytes form a value from 0–16383, with 8192 as the center. In practice, you just need to map the CCs you want (e.g., CC 7 for volume) and ensure the channel matches on both devices.
In my shows with an Ableton Push controller and a suite of hardware synths, I always route everything through a MIDI-USB interface that preserves timing and avoids "ghost notes." I set the Push to send Note On/Off on channel 1 and assign the knobs to CC 10–20; the synthesizer receives those messages and responds instantly. For debugging, I use a tool like MIDI-OX (Windows) or MIDI Monitor (macOS) to visualize the packets and confirm the values are within the expected range. If you're working with pitch bend, remember that some plugins require the range to be set (±2 semitones by default). A great resource for diving deeper is Robert Guérin’s book *MIDI Power!*, and the official MIDI 1.0 specification, which is available for free on the MIDI Manufacturers Association’s website.
MIDI fundamentally works with three-byte messages like “note-on/off”, “control-change”, and “pitch-bend”; for example, 0x90–0x9F is note-on, 0x80–0x8F is note-off, 0xB0–0xBF is control change, and 0xE0–0xEF is pitch-bend. When you plug a synth keyboard into another sound engine on a live stage, the played note sends the channel and command in the first byte (e.g., 0x90), the note number (0–127) in the second byte, and the velocity (0–127) in the third. Control changes follow the same structure with a control number and value. Pitch-bend uses a 14-bit resolution (LSB+MSB) to convey direction and amount in two bytes. These packets travel over a serial line at 31.25 kbaud and arrive within 1–2 ms, so the latency is barely noticeable.
A similar protocol, OSC (Open Sound Control), can carry thousands of data points simultaneously over UDP and has a more flexible, JSON-like message structure. While OSC’s high bandwidth and network-based nature shine in large stage setups and remote control, MIDI’s fixed three-byte structure and hardware-friendly 5 V TTL signal offer a low-cost, plug-and-play solution. In short, if you want a “plug and play” solution, MIDI is still king, but if you need multi-channel, high-resolution, network-synchronized control, OSC is worth a look.