Transports

MIDI messages are the same on every wire. What changes is how bytes, or UMP packets, are framed, timed and powered. This page covers the five-pin cable, USB, Bluetooth LE and the network.

At a glance

5-pin DIN

The original MIDI 1.0 transport is still common on synths, drum machines and modular gear. It is an asynchronous serial link: 1 start bit, 8 data bits (LSB first), no parity and 1 stop bit, at 31,250 bit/s ±1%. Each byte takes 10 bit-times, or 320 µs. A 3-byte Note On takes 960 µs, so a ten-note chord is spread over roughly 10 ms. That is one reason for running status, which trims it to about 6.7 ms.

Current loop and opto-isolation

The signal is a ~5 mA current loop, not a voltage. The transmitter sources current on pin 4 and sinks it on pin 5. At the receiver, that current drives the LED of an opto-isolator, so the two devices' grounds never connect. This is why MIDI rarely causes ground-loop hum.

The 2014 MIDI 1.0 Electrical Specification Update added 3.3 V transmitters and adjusted resistor values:

The receiver uses a fast opto-isolator such as the 6N138 or H11L1, with a series resistor (220 Ω is typical) and a reverse-protection diode across the LED. MIDI THRU should copy the IN signal electrically. A long chain of THRUs gradually distorts the bit timing, so long chains are best split with a THRU box.

TRS (3.5 mm) MIDI

Compact devices often use 3.5 mm TRS jacks with a breakout adapter. MMA document CA-033 (2018) standardized the wiring as Type A. An older convention, Type B, swaps tip and ring and is still found on some devices. Plugging a Type B device into a Type A adapter usually doesn't damage anything; it just doesn't work.

USB-MIDI 1.0

The USB Device Class Definition for MIDI Devices (v1.0, 1999) lets class-compliant devices work without vendor drivers on macOS, Windows, Linux, iOS and Android. MIDI data travels over bulk endpoints in 32-bit USB-MIDI Event Packets:

The Cable Number picks one of up to 16 virtual cables (ports) on the endpoint. The Code Index Number (CIN) classifies the message so the host knows how many of the three bytes are valid. Unused bytes are padded with 0. Note On, channel 1, middle C, velocity 100 on cable 0 is 09 90 3C 64.

SysEx is split into 3-byte chunks with CIN 0x4, and the last chunk uses CIN 0x5, 0x6 or 0x7 depending on how many bytes remain, including the closing F7. Running status is not used on USB; every packet carries its full status byte.

USB MIDI 2.0

The USB MIDI 2.0 device class (2020) keeps backward compatibility through USB alternate settings:

• Alternate Setting 0 is a normal USB-MIDI 1.0 interface, so older hosts keep working.
• Alternate Setting 1 carries Universal MIDI Packets directly over the bulk endpoints.
• Group Terminal Blocks in the descriptors say which UMP groups exist and whether they are inputs, outputs or both. At runtime, UMP Function Blocks give the richer picture.

Hosts with MIDI 2.0 drivers (macOS 11+, Linux 6.5+, Android 13+, Windows MIDI Services) select Alternate Setting 1. Other hosts use Alternate Setting 0. On microcontrollers, TinyUSB has MIDI 1.0 device support, and UMP drivers such as tusb_ump add MIDI 2.0.

BLE-MIDI

MIDI over Bluetooth Low Energy (2015) is built into macOS, iOS, Android 6+ and, more recently, Windows. A device exposes one GATT service with one characteristic. The characteristic supports read (which returns an empty payload), write without response, and notify.

Packet format

Each BLE packet carries one or more MIDI messages with a 13-bit millisecond timestamp:

• Header byte: bit 7 = 1, bit 6 = 0, bits 5–0 = the upper 6 bits of the timestamp.
• Timestamp byte: bit 7 = 1, bits 6–0 = the lower 7 bits of the timestamp. One comes before each MIDI message in the packet. Because its top bit is set, it can't be mistaken for a data byte.
• Then the MIDI message itself. Running status is allowed within a packet, and SysEx can span several packets.

80         header: timestamp high bits = 0
81         timestamp low bits = 1   → t = 1 ms
90 3C 64   Note On C4, velocity 100
81         timestamp (t = 1 ms)
3E 64      Note On D4, velocity 100 (running status)

The timestamp wraps every 8,192 ms. Receivers use it to place events correctly in time, because BLE delivers data in bursts once per connection interval. The spec recommends an interval of 15 ms or less, and 7.5 ms is the minimum BLE allows. Expect more latency and jitter than over a cable, and choose USB or DIN when timing is critical.

RTP-MIDI (AppleMIDI)

RTP-MIDI (RFC 6295, which replaced RFC 4695) carries MIDI over IP in RTP packets. A recovery journal lets a receiver rebuild the important state (notes, controllers, program) after a lost packet without retransmission. Apple's AppleMIDI session protocol, built into macOS and iOS as "Network MIDI", is the de facto way to set up sessions:

• Each session uses two consecutive UDP ports: a control port N (even) and a data port N+1. 5004/5005 is a common default.
• Session commands are invitation (IN), accept (OK), reject (NO), end (BY), clock synchronization (CK) and receiver feedback (RS).
• Sessions are advertised over Bonjour/mDNS as _apple-midi._udp.
• On Windows, use Tobias Erichsen's rtpMIDI driver. On Linux, rtpmidid. On microcontrollers, the Arduino AppleMIDI library.

Network MIDI 2.0 (UDP)

Published by the MMA and AMEI in 2024, Network MIDI 2.0 sends UMP over UDP. It defines mDNS discovery, session setup with optional authentication, and retransmission of recent packets to recover from loss. It is to MIDI 2.0 what RTP-MIDI is to MIDI 1.0, and is a natural fit for UMP-native stacks such as Windows MIDI Services.

ipMIDI and other approaches

ipMIDI sends raw MIDI bytes in UDP multicast packets (group 225.0.0.37, one port per MIDI port starting at 21928). It has no sessions and no recovery, but it is simple and is supported by tools such as QmidiNet. For tempo sync rather than MIDI messages, many applications use Ableton Link.