If you've ever connected an MPE controller to a hardware synth with a 5-pin DIN cable, played a five-note chord, leaned into all five fingers, and heard the expression turn lumpy — congratulations, you found the edge of a standard designed in 1983.

This isn't a fault in your gear. It's arithmetic, and it's worth understanding, because the fix is usually trivial once you know what's happening.

What a DIN cable can carry

Classic MIDI runs at a baud rate of 31,250 bits per second. Each byte on the wire is framed with a start bit and a stop bit, so a byte costs 10 bits, not 8. That works out to 3,125 bytes per second.

A typical MIDI channel message is three bytes — status, data, data — so it occupies 30 bits. Divide it out and the wire tops out at roughly 1,040 messages per second, total, for everything travelling down that cable.

That number is fine for normal keyboard playing. A busy passage might generate a few dozen messages a second. It is emphatically not fine for MPE.

Where MPE spends the budget

MPE gives every held note its own channel and its own three continuous dimensions:

Suppose you hold five notes and your controller updates all three dimensions for each note at 100 times per second — a modest rate for a surface that's trying to feel continuous. That's 5 × 100 × 80 bits, or 40,000 bits per second, against a budget of 31,250.

You're over. The interface buffers, then drops or delays messages, and what you hear is expression that lags, stair-steps, or freezes on one note while another keeps moving.

Three fingers at that rate sits around 24,000 bits/sec and squeaks through. Two fingers is comfortable. The wall arrives somewhere around four simultaneous notes, which is exactly where most people first notice the problem — playing chords, not lines.

The trick that doesn't work here

Ordinary MIDI has a compression feature called running status: if you send a series of messages with the same status byte, you can omit the status byte on all but the first, saving a third of the traffic.

MPE defeats this almost entirely. The whole point of MPE is that consecutive messages belong to different notes on different channels, so the status byte changes nearly every time. The one optimisation that would have rescued DIN bandwidth is structurally unavailable to the thing that needs it most.

Why USB behaves differently

USB MIDI doesn't use the 31,250 baud rate at all. It moves MIDI as packets over a far faster bus, and the practical throughput is orders of magnitude higher — comfortably enough for ten-finger MPE with all dimensions active.

There's one wrinkle worth knowing: USB devices are polled by the host at 1 ms intervals, so data arrives in bursts rather than as a continuous trickle. A huge amount can move in each burst, but no burst happens more often than once per millisecond. In practice this is inaudible for MPE. It only becomes relevant when you're chasing sub-millisecond timing, which MPE expression is not.

The upshot is simple: if your synth has a USB MIDI port, use it. A DIN connection to an MPE-capable hardware synth is a compatibility fallback, not the intended path.

Practical fixes when you're stuck on DIN

Sometimes you have no choice — vintage gear, a Eurorack MIDI-to-CV module, a fixed stage rig. Options, roughly in order of how much they cost you musically:

Lower the update rate on the controller. Most MPE surfaces let you set how often they emit continuous data. Dropping from 200 Hz to 100 Hz halves your traffic and is usually imperceptible on pads and sustained material.

Turn off dimensions you aren't using. If a patch ignores CC74, stop sending it. That's 30 bits per note per update recovered for free — often the single biggest win.

Reduce polyphony. Not a satisfying answer, but a three-voice MPE part over DIN is reliable in a way a six-voice one isn't.

Split across two cables. If your interface and instrument allow it, sending two MPE zones down two physical cables genuinely doubles your budget.

Move the expensive part upstream. Record the full-resolution MPE performance into your DAW over USB, then send a thinned version to the hardware on playback. You keep the original take intact and only the hardware sees the reduced stream.

The longer view

MIDI 2.0 addresses this properly — higher resolution, per-note controllers as first-class citizens, and transports built for the data rates involved. The specification work is public at midi.org, and DAW and OS support has been arriving steadily. But MIDI 2.0 runs over USB and network transports, not over 5-pin DIN.

So the old cable isn't going to get faster. If you're building a rig around per-note expression, plan your connections around that fact from the start, and you'll never meet the wall at all.