MIDI 1.0 was specified with a serial rate of 31,250 bits per second, and that number has been carried unchanged through four decades of hardware. It is one of the few figures in this entire subject area that is a genuine specification constant rather than somebody's measurement, which makes it unusually safe to reason from — and the reasoning produces a concrete, checkable explanation for a problem a lot of people have and misattribute.
The problem: you sweep a stick mapped to a filter on a hardware synth over a DIN cable, and everything gets late. Notes arrive behind the beat, the sweep itself lags your hand, and if you are slaving the synth's clock, the tempo wobbles. None of that is a fault. All of it is arithmetic.
- 31,250 bits per second is the MIDI 1.0 serial rate, specified in the MIDI 1.0 core specification.
- Ten bit periods per byte with standard async framing, so each byte occupies 320 microseconds and a three-byte message occupies 960.
- That caps a DIN link at roughly a thousand three-byte messages per second, total, across all channels.
- A stick sweep can exceed that trivially, especially on 14-bit pairs, which is why hardware rigs choke where software rigs do not.
- USB MIDI and virtual ports are not bound by it — the rate applies to the DIN wire, not to MIDI everywhere.
Where does 31,250 bits per second come from?
From the MIDI 1.0 specification itself, which defines the electrical and serial characteristics of the hardware interface along with the message format. The MIDI Association's core specification page is the primary reference, and the message overview covers the data format side.
The rate was chosen in the early 1980s to be achievable with the cheap microcontrollers of the day while being fast enough for musical use — a divider from common clock crystals of the era. The important thing for us is not the history but the permanence: it was never raised, so a DIN cable today runs at exactly the same rate as a DIN cable in 1983. Every modern synth with a five-pin socket is talking at that speed.
How long does a MIDI message actually take?
MIDI uses standard asynchronous serial framing: one start bit, eight data bits, one stop bit. Ten bit periods per byte. That framing is part of the specification and it is why the practical byte rate is not simply the bit rate divided by eight.
The arithmetic follows directly:
Bit period = 1 / 31250 = 32 microseconds
Byte on wire = 10 bit periods = 320 microseconds
3-byte message = 30 bit periods = 960 microseconds (~0.96 ms)
2-byte message = 20 bit periods = 640 microseconds
1-byte message = 10 bit periods = 320 microseconds
Three-byte messages per second, ceiling:
1 second / 960 microseconds = ~1041 messages/sec, TOTALEvery number there is derived from the specified rate and the specified framing. None of it is measured, and none of it varies by implementation. The ceiling applies to the whole link, not per channel — sixteen MIDI channels share one physical wire, so the budget is shared.
| Message | Bytes | Bit periods | Time on a DIN wire |
|---|---|---|---|
| Note On / Note Off | 3 | 30 | ~960 µs |
| Control Change | 3 | 30 | ~960 µs |
| Pitch Bend | 3 | 30 | ~960 µs — and natively 14-bit |
| Program Change | 2 | 20 | ~640 µs |
| Channel Pressure | 2 | 20 | ~640 µs |
| Timing Clock | 1 | 10 | ~320 µs |
| CC with running status | 2 | 20 | ~640 µs |
| 14-bit CC pair | 6 (or 4 with running status) | 60 (or 40) | ~1.9 ms (or ~1.3 ms) |
Why does a stick sweep saturate the link?
Because a stick can generate new values far faster than the wire can carry them. Work it through with real numbers.
Suppose a controller reports at a 1 ms interval — a full-speed USB device requesting a bInterval of 1, as derived in USB polling rate explained. During a fast sweep the value genuinely changes on most reports, so a naive bridge emits close to 1000 Control Change messages per second for that one axis. One axis alone is already at the link's total ceiling.
Now move two sticks at once — four axes — and add a trigger. Five controls, each wanting up to 1000 messages per second, against a link that can carry about 1041 in total. You are asking for roughly five times the available capacity, so four out of every five messages must wait. And the waiting compounds: each queued message pushes the next one later, so by the end of a two-second sweep the stream can be running substantially behind your hand, with no way to catch up until you stop moving.
Make those 14-bit pairs and you have doubled the demand again. This is the concrete reason the 14-bit decision needs to be per control rather than global — the argument in analog trigger resolution and 14-bit CC is as much about bandwidth as it is about audible resolution.
Why does this also wreck my tempo?
Because MIDI clock shares the stream. A Timing Clock message is a single byte, defined among the system real-time messages in the summary of MIDI 1.0 messages, sent at a fixed count per quarter note. It is small and frequent and it is supposed to be evenly spaced, because the receiving device infers tempo from the spacing.
Real-time messages are permitted to be interleaved even inside other messages, which helps — a clock byte does not have to wait for a Control Change already in flight to finish. What it cannot do is transmit while another byte is occupying the wire. So on a saturated link, clock bytes are delayed by up to a byte time each, variably, depending on what else is in flight at that instant. A receiver seeing unevenly spaced clock bytes infers an unevenly varying tempo, and you hear a wobble.
Two fixes, both straightforward. Reduce the Control Change traffic so the link is not saturated. Or move clock to a separate physical port so it never shares a wire with controller data. If your gamepad is acting as the clock master, as in MIDI clock sync from gamepad buttons, the second option is worth the extra cable. Multi-port routing is covered in routing one controller into two DAWs.
What is running status and how much does it save?
Running status is a MIDI 1.0 feature allowing consecutive messages of the same type on the same channel to omit the repeated status byte. The receiver remembers the last status it saw and applies it to subsequent data-byte pairs until a new status byte arrives.
// Without running status - three Control Change messages, 9 bytes
B0 4A 40 status=CC ch1, controller 74, value 64
B0 4A 41 status=CC ch1, controller 74, value 65
B0 4A 42 status=CC ch1, controller 74, value 66
// With running status - same three messages, 7 bytes
B0 4A 40 status byte sent once
4A 41 status inferred
4A 42 status inferredFor a long run of same-type, same-channel messages — exactly what a stick sweep produces — this converges on a one-third saving, taking a message from three bytes to two. That is not nothing: it raises the effective ceiling from around 1041 messages per second to around 1562.
Two caveats. Running status is broken by any interleaved message of a different type or channel, so a rig sending clock, notes and several controllers simultaneously gets much less benefit than the ideal case. And while the feature is specified and widely supported, a small number of receivers handle it poorly, so it is worth being able to turn off if a specific device misbehaves.
Does any of this apply to USB or virtual MIDI?
No, and this is the single most useful thing to understand about the whole topic. The 31,250 bits per second figure is a property of the DIN hardware interface, not of the MIDI message format. The same messages carried over a different transport travel at that transport's speed.
| Transport | Bound by 31,250 bps? | Notes |
|---|---|---|
| 5-pin DIN | Yes | The original serial interface; all the arithmetic above applies |
| USB MIDI | No | Packetised into USB-MIDI event packets per the USB MIDI class definition |
| Virtual MIDI port | No | In-memory handoff between processes; no serial wire exists |
| Network MIDI / RTP-MIDI | No | Carried over IP at network speeds |
| Bluetooth LE MIDI | No, but constrained differently | Bound by connection interval and packet size per the BLE-MIDI specification |
| MIDI 2.0 / UMP | No | Universal MIDI Packet, a different format entirely |
So a gamepad-to-virtual-port-to-DAW chain is not subject to this constraint at all, which is why a software rig happily absorbs a message density that makes a DIN rig fall over. The constraint reappears the moment a DIN cable enters the chain — typically at the interface feeding a hardware synth, as in gamepad to hardware synth over USB host. Virtual port behaviour per OS is covered in virtual MIDI ports explained and in the virtual port docs.
How do I keep traffic within budget?
Four measures, in order of how much they save for how little they cost.
- Suppress unchanged values. A 7-bit CC derived from a steady or slowly moving stick produces the same integer on consecutive reads. Sending it again conveys nothing. This alone removes the bulk of the traffic.
- Rate-limit per controller number. During genuinely fast movement every read does produce a new value, so cap the per-control send rate at something the destination can act on. A parameter nobody can hear changing a thousand times a second does not need to.
- Choose 14-bit per control, not globally. Reserve it for slow, exposed sweeps where stepping is audible. Everything else stays 7-bit.
- Enable running status for DIN segments. A third off consecutive same-type messages, for free, where the receiver supports it.
// Budget-aware CC emission
static uint8_t last_value[16][128];
static uint64_t last_send[16][128];
void emit_cc(int ch, int cc, uint8_t v, uint64_t now_us) {
if (v == last_value[ch][cc]) return; // (1) unchanged
if (now_us - last_send[ch][cc] < min_interval_us) return; // (2) rate limit
midi_send_cc(ch, cc, v);
last_value[ch][cc] = v;
last_send[ch][cc] = now_us;
}
A useful way to size min_interval_us is to divide your link's message ceiling by the number of controls that can move simultaneously, then allow headroom for notes and clock. On a DIN link with four axes in play, that lands you well under the per-axis ceiling and leaves the stream clear for the messages that carry musical information rather than gestural detail.
Does MIDI 2.0 solve this?
It changes the shape of the problem rather than removing the idea of a budget. MIDI 2.0 abandons the serial byte stream in favour of the Universal MIDI Packet, which carries much wider value fields in fixed-size packets rather than variable-length byte sequences. High-resolution Control Change stops needing a two-message pairing convention, which immediately halves the cost of the controls that most strain a MIDI 1.0 link.
It also brings bidirectional capability negotiation through MIDI-CI, so a device can discover what the other end supports rather than guessing — which matters for a gamepad bridge that currently has to make conservative assumptions about every destination. We cover the gamepad-specific consequences in MIDI 2.0 and gamepads and the discovery side in MIDI 2.0 Property Exchange.
What it does not do is make DIN cables faster. A MIDI 2.0 host talking to a 1983 synth is still talking at 31,250 bits per second, because that is the wire. The arithmetic in this post outlives the protocol revision for as long as five-pin sockets exist, which is to say indefinitely.
FAQ
What is the MIDI baud rate?
MIDI 1.0 specifies a serial rate of 31,250 bits per second on its original hardware interface, which is the rate used by 5-pin DIN connections.
How long does one MIDI message take to send?
With the standard framing of one start bit, eight data bits and one stop bit, each byte occupies ten bit periods, so a three-byte message occupies thirty bit periods at 31,250 bits per second.
Does USB MIDI have the same bandwidth limit?
No, because USB MIDI packetises MIDI messages into USB event packets carried at USB speeds, so the 31,250 bits per second figure applies to the DIN wire rather than to the protocol everywhere.
What is running status?
Running status is a MIDI 1.0 feature where consecutive messages of the same type and channel may omit the repeated status byte, reducing a three-byte message to two bytes on the wire.
Why does my hardware synth lag when I sweep a stick?
Because a stick sweep can emit far more Control Change messages than a serial MIDI link can carry, so messages queue and arrive progressively later until the sweep stops.
Can MIDI traffic affect my tempo?
Yes on a serial link, because clock bytes travel in the same stream as everything else, so a dense burst of Control Change data can delay them and produce an audible tempo wobble.
Put it into practice
If any part of your chain uses a DIN cable, open a MIDI monitor and sweep one stick while watching the message rate. If it is in the hundreds per second for a single axis, you are already near the wire's ceiling and everything else is queuing behind it. Download Universal Controller MIDI, turn on send-on-change with per-CC rate limiting, and watch that number fall without anything sounding different.