This article describes the generic MIDI architecture, independent of any platform implementation, API, or platform-specific features.
The MIDI protocol is designed for event-based communication. An event is an indication that something happened or will happen at a specified time. MIDI events are represented by messages, atomic bundles of information.
MIDI messages are encoded and delivered via a transport layer, abbreviated transport, which sends the raw MIDI data to the recipient who then decodes the data into messages.
Hardware-based MIDI transports include:
- MIDI 1.0 current loop with 5-pin DIN connector
- Bluetooth Low Energy (BLE)
A MIDI transport specification describes how to convey messages. Although the packaging of messages is transport-specific at the lowest level, at a higher level applications can consider a time-ordered sequence of messages to be a demarcated byte stream. This is possible because each message contains enough information to determine the total length of the message, provided the start of the message boundary is known.
Most MIDI messages are short (one to three bytes), yet there is the capability for longer messages via SysEx.
A timestamp is an optional label attached to a message at origination or upon receipt, depending on the transport. The timestamp is expressed in time units such as seconds or ticks.
In the absence of an explicit timestamp, the system must substitute the timestamp of the immediately preceding message or the current time. The accuracy of these timestamps, whether explicit or implicit, is an important aspect of the reliability of a MIDI-based system.
Timestamps are not part of the MIDI 1.0 protocol. They are often added as part of a platform-specific API. The BLE transport has timestamps to indicate the timing of the multiple individual messages sent within one BLE packet.
A peripheral provides input/output (I/O) capability for a computer. The terms MIDI peripheral and MIDI device commonly refer to any hardware or software module that supports the MIDI protocol. Within this document, MIDI peripheral refers to the physical entity and MIDI device describes the module that actually implements MIDI.
A port is an interface point between computers and peripherals.
MIDI 1.0 uses a female 5-pin DIN socket as the port. Each port is either OUT (source of MIDI data), IN (sink for MIDI data), or THRU (meaning an IN which is directly routed to an OUT).
Other transports such as USB and BLE extend the port concept.
A MIDI device has at least one OUT port, IN port, or both.
The MIDI device supplies stream(s) of messages originating at each OUT port, and receives stream(s) of messages arriving at each IN port. The terms IN and OUT are of course relative to one port; from the perspective of the other port the reverse term applies.
In the MIDI 1.0 transport, an OUT port connects to at most one IN or THRU port due to the nature of the current loop. In USB and BLE transports, the same is true at the lowest layer, though an implementation may re-condition the message stream so that it can be broadcast to multiple IN ports.
A MIDI 1.0 cable is the physical bundle of wires that connects an OUT port to an IN or THRU port. The cable carries data only.
Note: There are non-standard modifications to MIDI that supply power over the two unused pins. This is called phantom power.
A USB cable is similar, except there is a wide variety of connector types, and the IN/OUT/THRU concept is replaced by the host/peripheral role.
When operating in USB host mode, the host device supplies power to the MIDI peripheral. Most small MIDI peripherals take one USB unit load (100 mA) or less. However some larger peripherals, or peripherals with audio output or lights, require more power than the host device can supply. If you experience problems, try another MIDI peripheral or a powered USB hub.
Each MIDI message stream is multiplexed among 16 channels. Most messages are directed at a specific channel, but there are message types that aren't channel-specific. Conventionally the channels are numbered one to 16, though represented by channel values of zero to 15.
If the application needs more than 16 channels or a higher throughput than one message stream can support, then multiple ports must be used.
In MIDI 1.0, this is accomplished by multiple cables connecting pairs of ports.
In the MIDI over USB transport, a single USB endpoint can support multiple ports, each identified by a cable number [sic]. According to the USB MIDI specification, the cable number identifies the virtual port within the endpoint.
Note: port number would have been a more accurate term, given that it identifies a port.
Thus a single USB physical cable can carry more than one set of 16 channels.
As noted in the introduction, these generic MIDI concepts apply to all
implementations. For the interpretation of the concepts on the Android
platform, see the
Android MIDI User Guide for