How MIDI 2.0 Devices Discover Profiles Automatically

MIDI 2.0 revolutionizes hardware and software communication by replacing static, one-way messaging with dynamic bidirectional negotiation. This article explains how two MIDI 2.0 devices automatically discover each other's configuration profiles using MIDI Capability Inquiry (MIDI-CI). Through this standardized discovery handshake, connected gear can detect capabilities, exchange supported profile lists, and automatically map controls for seamless interoperability without requiring manual user configuration.

The Foundation: Bidirectional Communication and MIDI-CI

Unlike MIDI 1.0, which sent data blindly from an "Out" port to an "In" port, MIDI 2.0 mandates a bidirectional pathway. This two-way communication enables devices to talk back and forth over standard 5-pin DIN, USB, network connections, or the Universal MIDI Packet (UMP) format.

The mechanism responsible for automatic feature detection is MIDI Capability Inquiry (MIDI-CI). MIDI-CI operates across three core pillars: Protocol Negotiation, Property Exchange, and Profile Configuration. Profile Configuration specifically dictates how devices agree on functional rules for specific instrument types or controllers.

Step 1: Initial Discovery Handshake

When two MIDI 2.0 devices are connected and powered on, the discovery process begins automatically:

1. Discovery Inquiry: Device A sends a standardized MIDI-CI "Discovery Inquiry" message across the connection. This message contains Device A's unique System Exclusive Manufacturer ID, Device Family, Device Model Number, and Software Revision Level.
2. Discovery Reply: If Device B supports MIDI-CI, it responds with a "Discovery Reply" detailing its own identification data and a bitmap of supported MIDI-CI categories. To enable profile discovery, Device B flags support for the Profile Configuration category.

Step 2: The Profile Inquiry Request

Once the devices confirm that both support MIDI-CI Profile Configuration, one or both devices initiate the profile discovery phase:

• The inquiring device sends a Profile Inquiry message.
• This message can target a specific MIDI channel, a group of channels, or the entire device (Function Block).
• The inquiry explicitly requests a list of all profiles the receiver understands, as well as which profiles are currently active.

Step 3: Profile Inquiry Reply

In response to the inquiry, the receiving device transmits a Profile Inquiry Reply. This response contains a structured payload with two essential lists:

1. Enabled Profiles: Profiles that are actively running and processing data on that specific channel or group.
2. Supported Profiles: Inactive profiles that the device can switch to if requested.

Each profile is identified by a unique 5-byte Profile ID. Standardized profiles defined by the MIDI Association cover common musical contexts (such as Drawbar Organ, Piano, Microtonal Tuning, or MIDI Polyphonic Expression / MPE), while manufacturer-specific profiles cover proprietary workflows.

Step 4: Profile Activation and Synchronization

After receiving the reply, the inquiring device analyzes the list:

• Profile Negotiation: If the inquiring device prefers a supported profile that is currently inactive (for example, switching a synthesizer from a generic controller map to an MPE profile), it sends a Set Profile On message for that specific 5-byte Profile ID.
• Confirmation: The recipient adjusts its internal engine, updates its control mappings, and replies with a Profile Enabled acknowledgment.
• Profile Deactivation: If a configuration is no longer needed, either device can send a Set Profile Off message, returning the channel to its default behavior.

By completing this inquiry-and-reply sequence within milliseconds of connection, MIDI 2.0 devices achieve instant, automatic configuration tailored to the specific instruments and controllers in use.