MIDI 2.0 Property Exchange Feature Discovery

MIDI 2.0 Property Exchange fundamentally changes music hardware integration by allowing connected devices to automatically query, understand, and configure each other's capabilities without manual MIDI mapping. Built on top of MIDI Capability Inquiry (MIDI-CI), Property Exchange uses standardized JSON-based messaging to retrieve detailed device metadata, including parameter names, control ranges, patch lists, and visual layouts. This article explains the underlying mechanism that enables this automatic feature discovery between modern MIDI instruments and controllers.

The Foundation: MIDI Capability Inquiry (MIDI-CI)

Before Property Exchange can take place, two connected devices must confirm they can speak MIDI 2.0 through MIDI Capability Inquiry (MIDI-CI). Delivered over the Universal MIDI Packet (UMP) architecture via System Exclusive messages, MIDI-CI executes an initial handshake. During this handshake, devices establish mutual support for three core pillars: Protocol Negotiation, Profile Configuration, and Property Exchange. Once both endpoints acknowledge that Property Exchange is supported, the feature discovery process begins.

JSON-Based Metadata Modeling

Property Exchange eliminates the guesswork of MIDI 1.0 by using standard JSON (JavaScript Object Notation) payloads to describe device architecture. Rather than relying on static control change (CC) numbers and manufacturer-specific SysEx implementations, a MIDI 2.0 instrument defines its parameters, values, and states as structured data models. This human-readable and machine-parsable format allows receiving devices, such as hardware controllers or Digital Audio Workstations (DAWs), to parse complex engine parameters into easily readable attributes like minimum and maximum values, data types, and display units (such as Hertz, decibels, or milliseconds).

The Discovery Workflow

Feature discovery via Property Exchange follows a standard request-and-response workflow:

  1. Resource List Request: The querying device (such as a master keyboard) sends an inquiry message requesting the target device’s "ResourceList."
  2. Resource Cataloging: The target device responds with a JSON catalog containing all discoverable features it supports. These resources typically include parameter lists, current channel settings, sound program names, and mode configurations.
  3. Property Data Inquiries: The controller requests specific details for individual items found in the ResourceList using "GetData" requests. For example, it can request the schema for an instrument's filter section.
  4. Parameter Description Delivery: The target device sends back the exact specifications of the requested control, providing its full text name ("Cutoff Frequency"), its assigned CC or Per-Note Controller index, and its valid range.

Dynamic Bi-Directional Configuration

Because Property Exchange operates bidirectionally, feature discovery is dynamic rather than static. When a user changes a preset or alters a sound engine mode on a synthesizer, the synth notifies the controller using a "Notify" message. The controller then automatically updates its local display, renaming encoders and adjusting value readouts to match the new sound engine state.

Through this standardized discovery layer, MIDI 2.0 Property Exchange transforms MIDI from a blind, one-way command stream into an intelligent, self-describing network where controllers and software configure themselves instantly upon connection.