MIDI Polyphonic Expression (MPE) Specification

MIDI Polyphonic Expression (MPE) is an extension of the MIDI 1.0 protocol that allows independent expressive control of each note in a performance. In normal MIDI, channel-wide messages like pitch bend or modulation affect all notes on that channel simultaneously. MPE solves this by assigning each note its own MIDI channel, so that formerly global controls (pitch, timbre, pressure, etc.) can be applied per-note without influencing others. This approach greatly increases the expressive possibilities—musicians can bend the pitch of one note in a chord or add vibrato to a single note, for example, which was impossible with standard MIDI.

Importantly, MPE does not introduce new MIDI message types; it uses the same MIDI 1.0 messages (note on/off, pitch bend, CC, aftertouch, etc.) but organizes them across channels in a special way.

Structure of MIDI Messages in MPE

MPE leverages standard MIDI messages to transmit per-note expression. Under the hood, the data format of each message remains the same as in MIDI 1.0; what changes is how these messages are distributed across channels. Below are the key message types and how MPE uses them for per-note control:

• Note On/Off: Each note is still triggered with a Note On message (status byte 0x90–0x9F) and released with a Note Off (0x80–0x8F, or Note On with velocity 0). The difference in MPE is that each note’s Note On/Off is sent on a separate member channel dedicated to that note. The message structure at the byte level is unchanged: the status byte encodes the command (Note On/Off) and channel, followed by a data byte for the note number (0–127) and one for velocity (0–127). Release velocity (if used) is sent as the second data byte of a Note Off, allowing MPE controllers to convey “lift” speed per note as well.

• Pitch Bend: MPE uses standard pitch bend messages to allow independent pitch modulation (glide or vibrato) for each note. A pitch bend message consists of a status byte 0xE0–0xEF (which encodes the command and channel) and two 7-bit data bytes that form a 14-bit value. The first data byte is the least significant 7 bits and the second is the most significant 7 bits of a 14-bit bend value (0–16383). Values above 8192 bend the note upward in pitch, and below 8192 bend downward, with the range in semitones set by the receiver’s pitch bend sensitivity. By default, MPE uses a wide pitch bend range (often ±48 semitones) on per-note channels to accommodate large pitch slides. This means the synthesizer interprets the full 14-bit range as up to 4 octaves of pitch movement for individual notes. (In contrast, the master channel typically remains at a standard pitch bend range like ±2 semitones for overall pitch wheel moves) Despite the extended range, the format is still the usual MIDI pitch bend message – just sent on a per-note basis. For example, if one note is on channel 3, bending only that note involves sending pitch bend messages on channel 3 (leaving other notes on other channels unaffected).

• Timbre/Modulation (CC): Continuous controller messages (CC) are used in MPE to add per-note modulation. MPE designates MIDI CC #74 (often labeled “Brightness” or timbre) as a standard per-note modulation controller. Like any MIDI CC, this is a 3-byte message: status 0xB0–0xBF (with the channel), a data byte for the controller number (74 in this case), and a data byte for the 7-bit value (0–127).
  On an MPE controller, moving a finger in the Y-axis (for example, sliding up and down a key or pad) often sends CC74 messages on that note’s channel to alter its timbre or another assigned parameter.
  Modulation wheel (CC #1) or other CCs can also be used in MPE, but by convention those that affect all notes (like a global mod wheel or pedal) are sent on the master channel, whereas CC74 is the typical per-note CC. MPE doesn’t prevent using other CCs per note – they are simply MIDI messages on that note’s channel – but most MPE synthesizers specifically listen for CC74 as the per-note “slide” or modulation dimension.

• Aftertouch/Pressure: MPE transmits per-note pressure using the Channel Pressure message (status 0xD0–0xDF with one data byte for pressure value 0–127). Channel Pressure is a channel-wide message in MIDI, but in MPE each note has its own channel, so it effectively becomes per-note aftertouch. This corresponds to the “press” or Z-axis dimension of touch on MPE controllers (how hard you continue to press each note). For example, if a key is pressed harder while holding a note on channel 5, the controller sends a Channel Pressure message on channel 5 with a higher value.
  The receiving MPE synth applies that pressure value to only the voice playing on channel 5. Notably, MIDI also has a Polyphonic Key Pressure message (which includes a note number in the message), but the MPE specification avoids using polyphonic aftertouch on individual note channels (since each channel carries only one note, channel pressure is more efficient. For compatibility, the spec allows polyphonic key pressure on the master channel if needed (for a controller that only generates poly-aftertouch), but member channels use channel pressure for simplicity.

• Other Messages: Any MIDI message that is channel-specific can be utilized in MPE on either the master or a member channel. For instance, sustain pedal (CC #64) and Program Changes are typically sent on the master channel so they apply to the entire zone of notes. Bank Select, volume, pan, or other global controls would also be on the master channel. High-resolution velocity (Note On velocity is already per note by nature) and Release Velocity remain as defined in MIDI.
  MPE doesn’t alter the 7-bit limitation of most controllers except pitch bend (which was always 14-bit); however, it does allow richer combinations of these messages simultaneously.
  The MPE specification also defines a specific Registered Parameter Number (RPN) to configure MPE mode. In practice, an MPE controller or synth uses RPN #6 to set up the channel zone (i.e. how many channels are reserved for that MPE zone). For example, sending an RPN 6 value of 10 on the master channel could configure an instrument to use channels 2–11 for notes (a 10-voice MPE zone).
  Likewise, RPN #0 (Pitch Bend Range) is used to ensure the pitch bend sensitivity on each channel is set appropriately (e.g. ±48 semitones) on both the controller and synth. All of these are standard MIDI 1.0 messages – MPE simply establishes conventions so that controllers and synths agree on their usage.

Master and Member Channels in MPE

In MPE, the 16 MIDI channels are divided into one or more zones, each consisting of a Master channel and several Member channels. The master channel is a reserved MIDI channel that carries messages affecting the zone as a whole, while member channels are used for individual notes.
Typically, an MPE controller uses one zone across the MIDI channel range. By default this is the “Lower Zone,” meaning Channel 1 is the master and Channels 2–16 serve as member channels for notes. This yields up to 15 simultaneous notes of polyphony (since 15 channels are available for individual notes). It’s also possible to configure an “Upper Zone” where Channel 16 is the master (and channels 15 downwards are notes), or even to split into two zones (for example, one zone could use channels 1–8 and another 9–16, each with its own master). In any case, each zone sacrifices one channel for global use, and the remaining channels are pooled for per-note use. The master channel is where common controls are sent: for example, overall sustain pedal (CC64), volume or pan (if used), program changes, or a global pitch bend that should move all notes at once. Rather than duplicating these messages on every note channel, it’s more efficient and logically clear to send them once on the master channel (the synth will apply them to all voices in the zone).

The member channels are allocated to notes dynamically. When you play a note on an MPE controller, it picks an unused member channel and sends the Note On (plus that note’s subsequent expression messages) on that channel. That channel is now “owned” by that note for as long as it’s held. If you play a chord of several notes, each one goes out on a different channel (for example, the first note on channel 2, the second on 3, the third on 4, and so on).
As you release notes (sending Note Offs), their channels become free to be reused for new notes. The MPE specification encourages that “wherever possible, every sounding note is temporarily assigned its own MIDI Channel between its Note On and Note Off”. This ensures that channel-wide messages like pitch bend or CC74 can be directed to only that note.

The allocation algorithm for channels can vary by controller, but a common approach is a simple round-robin or first-available assignment. For example, if channels 2–16 are the pool and you press three notes, they might go to channels 2, 3, and 4 respectively. If you then press a fourth note, it would go to channel 5, and so on. If an earlier note (say the one on channel 2) is released, the next new note might reuse channel 2 once it’s free. Some implementations try to reuse the most recently freed channel or the oldest channel in use to optimize voice reuse. The exact strategy isn’t usually noticeable to the performer – it just happens behind the scenes to maximize the number of independent notes.

It is important to note that the number of member channels (and thus the maximum polyphony with independent expression) is limited. If you exceed the number of available channels by playing more notes than the MPE zone can support at once, the controller has no choice but to put two notes on the same channel, meaning those two notes will share expression data. In such a case, all notes will still sound (MIDI can play multiple notes on one channel), but you lose the ability to control them separately – any pitch bend or CC sent on that channel will affect both notes.
The MPE spec explicitly states: if there are more active notes in a zone than channels, “two or more notes will have to share the same Channel… under such circumstances, all notes will continue to sound, but will no longer be uniquely controllable”. Practically, most MPE controllers are designed with a certain channel count that matches their likely maximum fingers on surface (often 5–10), so running out of channels is rare. However, the channel count is usually configurable.
As mentioned, MPE defines an RPN message to set the size of a zone (number of note channels). A synth or controller can use this to negotiate how many channels to use if, say, a synth has a limited polyphony.
For instance, if a synthesizer can only play 8 voices, the controller can be instructed (via RPN #6 on the master channel) to only use channels 2–9 for notes. This flexibility ensures efficient use of MIDI channels and compatibility with the polyphony limits of hardware.

MPE and Standard MIDI Device Compatibility

Because MPE is implemented using standard MIDI messages, it is technically backward-compatible with existing MIDI devices – it doesn’t introduce a new protocol, it “remains fully compatible with MIDI” at the data level. However, interpreting that data correctly requires both the controller and the synth (or DAW) to understand the MPE conventions. Using an MPE controller with a non-MPE (traditional) synthesizer can present some challenges, and vice-versa. Let’s consider the scenarios and solutions:

• MPE Controller to Standard Synth: Suppose you connect an MPE controller (like a ROLI Seaboard or LinnStrument) to a typical MIDI synth or sound module that isn’t MPE-aware. The controller will, in MPE mode, send each note on a different channel (often starting from MIDI channel 2 upward).
   A standard monotimbral synth usually listens on only one MIDI channel (or “Omni” on all channels merged). If it’s configured to listen on channel 1 (a common default) and your MPE controller is sending notes on channels 2–16, you may initially hear nothing — the synth is ignoring channels 2–16 since it expects notes on channel 1.
  The flip side is that some synths in Omni mode will respond to all channels, but if they don’t know about MPE, they might treat all channels as the same voice. In that case, you would hear notes, but the per-note separation is lost; for example, pitch bends on channel 3 might also bend a note that the synth received on channel 4 if it merges them internally.
  On a multi-timbral sound module (like a workstation or rack synth), different MIDI channels typically feed different sound patches. Sending note #1 on channel 2 and note #2 on channel 3 could trigger two separate instruments unless the module is configured with the same sound on those channels. This can lead to inconsistent timbre across the notes of what you intended as one instrument.
  Solution: Many MPE controllers offer a switch or mode to disable MPE and send all notes on a single channel (usually channel 1) for compatibility. If you set the controller to “single channel” mode, it behaves like a normal MIDI keyboard: all notes and their pitch bends/CCs go out on one channel. You lose the polyphonic expressive control (because now a pitch bend will affect all notes together), but the synth will respond normally. Another solution is to configure the receiving synth to accommodate MPE data.
  If the synth is multi-timbral, you can often set up a “stack” or multi where the same patch is assigned to a range of MIDI channels. For instance, load the identical synth sound on 15 parts, each listening on channels 2–16. Then the MPE controller’s output on 2–16 will essentially play 15 voices of that sound, each on its own channel. This mimics MPE operation. It’s a bit labor-intensive and relies on the synth’s capabilities, but some advanced users have done this before official MPE support was common.
  Increasingly, new hardware and software synths provide a dedicated MPE mode that automates this setup. In MPE mode, the synth knows to treat a block of MIDI channels as one instrument. For example, recent firmware updates for synthesizers like the Prophet/DSI OB-6 allow an MPE mode where the synth listens to channel 1 as global and channels 2–16 for voices.
  In short, to use an MPE controller with a non-MPE synth, you either constrain the controller to “normal MIDI” operation or configure the synth to accept multiple channels as one. One more consideration: global messages (on the master channel). If your synth isn’t aware of MPE, things like sustain pedal sent on channel 1 might not affect notes on other channels. A workaround in a multi-timbral setup is to clone those pedal CC messages to all used channels (or rely on Omni mode if it applies pedal globally). These kinds of hurdles are exactly why explicit MPE support (where the synth firmware handles it for you) is so valuable.

• Standard MIDI Controller to MPE Synth: In this case, you have a synth or software instrument that expects MPE input (multiple channels), but you’re driving it with a conventional single-channel controller (e.g., a normal MIDI keyboard or older DAW piano roll).
  If the MPE synth is left in MPE mode, it might be looking, for example, for notes on channels 2–16 (assuming a lower zone configuration with channel 1 as master). If you send it normal MIDI on channel 1 only, the synth could either ignore those notes (since it doesn’t expect actual note data on the master channel), or it might treat them differently.
  Some MPE synths are intelligent enough to still respond to single-channel input in a basic way, but others might require you to turn MPE mode off for normal MIDI, The straightforward solution is to toggle the synth to a “legacy MIDI” or regular mode if it has one.
  Many software instruments have an MPE toggle – turning it off means the instrument will treat all incoming MIDI on one channel as usual, so your normal controller works (you just won’t get per-note expression without an MPE controller). If the synth doesn’t have a switch, another trick is to use the “Upper Zone” configuration on the synth. For example, if the synth can be set such that channel 16 is master and 1–15 are notes, then your normal controller sending on channel 1 will trigger a voice (because channel 1 is now a note channel in that scheme). However, any channel-wide messages like pitch bend from that controller will only affect that one channel’s notes (which is fine, since you’re only playing on one channel anyway).
  Essentially, an MPE synth expects multiple channels of input, but it can generally still play notes from just one channel; you just won’t be utilizing the MPE aspect. As a rule of thumb, when using a non-MPE controller, disable MPE on the synth or configure both to effectively operate in standard MIDI mode.

• DAWs and MIDI Routing: Compatibility issues aren’t limited to hardware. When recording or routing MPE data in a DAW or sequencer, special care is needed. A traditional MIDI track assumes one channel of data. If an MPE controller sends multiple channels into a single track, an unaware DAW might merge or “sum” them, causing control messages to conflict. For example, two different notes sending pitch bends on channels 2 and 3 might be merged into one pitch bend lane, resulting in chaotic values that don’t match either note’s intended pitch.
  Modern DAWs like Bitwig, Cubase, Logic, and Ableton Live (11+) have explicit MPE support: they keep track of each note’s channel and allow per-note automation lanes. In those environments, using MPE is straightforward – you record and the DAW knows those MIDI events are tied to separate notes.
  In a DAW without MPE support, a workaround is to record each MIDI channel to a separate track (or use a script/plugin that can split the stream by channel), then route those tracks to the MPE synth’s channels. This, however, complicates editing. The MIDI Manufacturers Association recognized this and made sure MPE had a path to integration in major software.
  Still, if you try to use MPE data with older MIDI utilities or across MIDI pipelines that assume a single channel, you might hit these compatibility issues. The solution is always to ensure both the sending and receiving side agree on whether they’re using MPE or not.

In summary, while the MIDI protocol underlying MPE is the same, using MPE really requires both ends to be configured for it. If not, you can usually fall back to standard MIDI behavior. It’s worth noting that as of the late 2010s, many manufacturers issued updates to make their instruments MPE-compatible (either adding an MPE mode or at least ensuring multi-channel handling). The industry trend is towards broader support, but when connecting new MPE gear to old MIDI gear, some setup adjustments are often needed to achieve the best result.

Timing and Throughput Considerations

One side effect of MPE’s per-note data streams is a significant increase in MIDI traffic. By design, MPE is “data-rich” – it generates a lot more MIDI messages in parallel than a comparable performance on a single channe. For example, imagine playing a four-note chord on an MPE controller and applying a smooth vibrato (pitch wobble) to each finger.
In standard MIDI, you might send one pitch bend message periodically that bends all notes together. In MPE, you are sending four separate pitch bend streams, one on each note’s channel, simultaneously. If each vibrato is, say, 20 messages per second, that’s 80 pitch bend messages per second instead of 20. Add to that per-note pressure data and timbre (CC74) sweeps, and the message count multiplies quickly with polyphony.
Channel 1 might also be sending sustain pedal or other global data. It’s easy to see how MPE can approach the limits of the MIDI 1.0 bandwidth. Traditional 5-pin MIDI has a fixed serial speed of ~31.25 kbit/s (roughly ~3125 bytes per second). This equates to about 1000 typical MIDI messages per second (a typical message is 3 bytes).
An expressive MPE performance can indeed generate on the order of hundreds of messages in a short burst. MIDI bandwidth saturation can result in subtle timing delays (MIDI messages might queue up and arrive a few milliseconds late) or even dropped messages in extreme cases. In practice, if you use a MIDI DIN cable and try to push very dense MPE data (for instance, a rapid glissando of many notes each with high-resolution bends), you may experience a slight lag or compression of the data.

USB MIDI, which is how most modern MPE controllers connect, has a much higher throughput (Full Speed USB MIDI handles 12 Mbit/s), so bandwidth is usually not a bottleneck with computer-based setups.
However, the processing load is still a factor. Each MIDI message has to be handled by the software/hardware synthesizer. MPE effectively asks the synth to do more work: it must track multiple streams of control and apply them to the correct voices. A powerful computer or a modern hardware synth can handle this, but on slower systems or when running many plugins, you might hit CPU limits sooner with MPE data than with simpler MIDI.
If you play many notes at once and assign many modulation sources, your computer might not be able to process all that data in real time without CPU overload. This is not so much an issue with the MIDI protocol itself as with the receiver’s ability to keep up with the flood of control changes.
Some synthesizers mitigate this by throttling the rate of less essential messages. For example, an MPE controller might send extremely high-resolution data, but the synth could internally smooth or down-sample the modulation to lighten the load.

For timing-critical performances, it’s wise to test the limits of your setup. If you find that very fast movements on multiple notes feel sluggish, you might reduce the data rate. Many MPE controllers provide settings for sensitivity or message rate (for instance, limiting how many pressure messages are sent per second) to tailor the performance vs. bandwidth trade-off. Also, consider using a direct USB connection or a high-speed MIDI interface for heavy MPE use, as older MIDI mergers or wireless MIDI links might choke on the throughput.
Another consideration is MIDI jitter – when sending many messages at once, the timing between note events and their associated control events could blur. A well-designed MPE controller will send critical messages in an order that makes musical sense (often, a Note On is immediately followed by initial pressure or pitch data on that same channel). But if the MIDI pipeline is congested, some of those messages might be ever so slightly delayed.
Fortunately, the human ear is somewhat forgiving with small timing differences, especially with continuous data like bends or pressure (they have a smoothing effect). It’s usually more important that note events themselves aren’t delayed too much. Ensuring the synth has a large enough buffer or using MIDI 2.0 (in the future) with higher resolution timestamps could further alleviate these concerns.

In summary, MPE’s rich expression means more MIDI data flying around. On modern systems this is generally handled well, but it’s possible to hit the ceiling of MIDI 1.0’s bandwidth in extreme cases. Musicians and developers should be mindful of the data density: utilize only as much resolution as needed for musical effect, and leverage the latest hardware or software improvements for handling MIDI.
The enhanced expressiveness of MPE is often worth the extra data, and with proper configuration and robust equipment, timing remains tight and performance smooth. The MPE specification was designed with these limitations in mind, and it represents a clever repurposing of MIDI’s 16 channels to dramatically increase musical expressivity while staying within MIDI 1.0’s technological constraints. Each note becomes its own “channelized” performance, and when managed well, the result is seamless, polyphonic expression that feels like a natural extension of the instrument rather than a stream of discrete MIDI messages.