MIDI-CI Explained: How Capability Inquiry Works

MIDI Capability Inquiry (MIDI-CI) is a foundational extension to the MIDI standard that allows devices to communicate bidirectionally, discover each other's capabilities, and automatically configure advanced features. This article explains what the MIDI-CI specification is, why it was developed as the gateway to MIDI 2.0, and the exact step-by-step mechanisms it uses to negotiate protocols, profiles, and device properties.

What is the MIDI-CI Specification?

Historically, MIDI 1.0 was a one-way communication protocol. A controller transmitted data blindly to a sound module without knowing if the receiving device understood the message, what sounds it possessed, or what parameters it could control.

The MIDI Association developed the MIDI-CI specification to transform MIDI into a bidirectional conversation. Operating over traditional 5-pin DIN cables, USB, or any modern transport layer, MIDI-CI works by utilizing specialized System Exclusive (SysEx) messages. It serves as a bridge that allows legacy MIDI 1.0 gear and modern MIDI 2.0 hardware to coexist seamlessly. Through MIDI-CI, devices ask questions, confirm shared abilities, and agree on how to interact before exchanging performance data.

The Discovery Phase: Establishing the Handshake

Before any negotiation can take place, connected devices must identify each other. MIDI-CI achieves this through a discovery process:

1. Discovery Request: When a device (the Initiator) connects to a MIDI network, it broadcasts a MIDI-CI Discovery message containing a randomly generated 28-bit source identifier known as a MIDI Unique Identifier (MUID).
2. Device Identification: The message includes basic hardware identification, such as manufacturer ID, device family, and model number.
3. Discovery Reply: Receiving devices (Responders) generate their own MUIDs and reply, confirming they support MIDI-CI and declaring which specific negotiation categories they support.
4. Backward Compatibility: If an older device does not respond to the MIDI-CI Discovery message, the Initiator concludes that the target only supports traditional MIDI 1.0 and defaults to standard behavior.

How MIDI-CI Negotiates Features: The Three Pillars

Once mutual support is confirmed, MIDI-CI negotiates features across three distinct functional categories: Protocol Negotiation, Profile Configuration, and Property Exchange.

1. Protocol Negotiation (Moving to MIDI 2.0)

Protocol Negotiation determines the language used for musical performance data.

• The Inquiry: An Initiator asks if the Responder can communicate using newer protocols, such as the Universal MIDI Packet (UMP) format used in MIDI 2.0, which offers 32-bit resolution and tighter timing.
• The Response: The Responder confirms whether it can switch to the requested protocol.
• The Switch: If both devices agree, they execute a synchronized switch to the new protocol. If either device declines, the connection remains on standard MIDI 1.0.

2. Profile Configuration (Standardizing Functional Behaviors)

Profiles define rules for specific types of musical instruments or controllers. For example, an "Analog Synth" profile expects specific controls for cutoff frequency and resonance, while a "Drawbar Organ" profile expects controls for drawbars, percussion, and rotary speaker speed.

• Profile Inquiry: A controller queries a synthesizer to receive a list of its supported profiles.
• Profile Activation: The controller sends a request to turn on a specific profile.
• Auto-Mapping: Once active, both devices bind their controls to the standardized profile mappings. Musicians no longer need to spend time manually mapping MIDI Continuous Controllers (CCs) between hardware units.

3. Property Exchange (Deep Data and Editor Integration)

Property Exchange allows devices to share complex configuration data, metadata, and visual assets. It uses standard JSON formatting wrapped inside Universal System Exclusive messages.

• Resource Discovery: Devices query each other for available resources, such as program lists, patch names, controller assignments, and effect states.
• Real-Time Data Transfer: A digital audio workstation (DAW) or hardware controller can request the current patch name and parameter values from a synthesizer. As parameters change on the synth, updated values are sent back to the controller via JSON.
• Graphical Interfaces: Property Exchange can transfer data describing a device's user interface, enabling a controller or computer to render an interactive software editor for a hardware synthesizer without requiring custom drivers.

Summary

The MIDI-CI specification transitions MIDI from an open-loop, one-way system into an intelligent, self-configuring network. By utilizing MUID handshakes, Profile Configuration, Property Exchange, and Protocol Negotiation, MIDI-CI enables devices to automatically discover what they can do together, upgrade their performance resolution, and configure controls without manual user intervention.