MIDI-CI: Capability Inquiry

MIDI-CI lets two devices find each other, see what the other supports, and agree on how to work together, all without user setup. It is made of Universal System Exclusive messages, so it works over MIDI 1.0 byte streams as well as over UMP.

MIDI-CI covers four areas:

• Management: discovery, MUIDs, ACK/NAK.
• Profile Configuration: switch on standard behaviors such as "Drawbar Organ", "MPE" or "Orchestral Articulation".
• Property Exchange: get and set structured data (patch lists, device info, parameter state) as JSON.
• Process Inquiry: ask a device for its current MIDI state, such as controller values (added in v1.2).

Message layout

Every MIDI-CI message starts with the same header:

MUIDs

A MUID (MIDI Unique Identifier) is a random 28-bit number that a device makes for itself when it starts MIDI-CI. It identifies the device for the rest of the session. 0x0FFFFFFF is reserved for broadcast and 0x0FFFFF00–0x0FFFFFFE are reserved. If a device sees another device using its MUID, it picks a new one and sends Invalidate MUID.

Management and discovery

Discovery is the first step. An Initiator broadcasts a Discovery Inquiry, and each Responder answers with its own MUID, its identity (SysEx manufacturer ID, family, model and software revision, the same fields as a Device Inquiry reply), a capability category bitmap saying which MIDI-CI areas it supports, and the largest SysEx message it can receive. After that, the two devices address each other directly by MUID.

Profile Configuration

A Profile is a published agreement about how a device of some kind responds to MIDI: which controllers do what, how notes map, and similar rules. Turning a profile on is a promise to behave that way. Profiles are named by a 5-byte Profile ID. Standard profiles begin with 7E; manufacturer-specific ones begin with the manufacturer's SysEx ID. A profile can apply to a single channel, several channels, a whole group, or a whole Function Block.

Adopted and in-progress profiles include the MPE Profile, Drawbar Organ, Rotary Speaker, Orchestral Articulation, Default Control Change Mapping, and others. See midi.org for the current list.

Property Exchange

Property Exchange (PE) moves structured data between devices: what patches exist, what the device is called, what its parameters are. Each request has a JSON header naming a resource, and an optional body that is usually JSON too. Large payloads are split into numbered chunks to fit the receiver's maximum SysEx size.

A Get for the device info resource looks roughly like this (shown with the JSON header as text):

F0 7E 7F 0D 34 02  <src MUID>  <dst MUID>
   01                       request ID
   19 00                    header length (25, 14-bit LSB first)
   {"resource":"DeviceInfo"}
   01 00                    number of chunks = 1
   01 00                    this chunk = 1
   00 00                    property data length = 0
F7

Commonly used resources:

With Subscription, an Initiator can ask to hear about changes to a resource, and the Responder sends updates as they happen. A DAW can use this to keep a patch name on screen in sync with the hardware.

Process Inquiry

Added in MIDI-CI 1.2, Process Inquiry asks a device to report its current MIDI state, such as the present value of each controller or pitch bend on chosen channels. The device answers with ordinary MIDI messages, framed between a reply and an end marker.

In practice

• MIDI-CI needs a bidirectional connection: a cable or port pair in each direction, USB, or a UMP Endpoint.
• Over UMP, MIDI-CI messages are carried as SysEx7 (MT 0x3) in the group that the Function Block uses.
• Devices must ignore MIDI-CI messages they don't understand. A Responder that doesn't support something answers with NAK.
• The MIDI 2.0 Workbench is the reference tool for testing MIDI-CI. The libraries listed under MIDI 2.0 include CI implementations.