MIDI 2.0 Property Exchange: JSON Patch Names

MIDI 2.0 revolutionizes musical instrument communication by replacing static, manual patch name lists with dynamic, bi-directional discovery through MIDI Capability Inquiry (MIDI-CI) Property Exchange. By leveraging standard JSON payloads encapsulated within System Exclusive messages, modern hardware synthesizers and software DAWs can directly negotiate and query device states. This article explains how MIDI 2.0 Property Exchange formats, requests, and transfers patch and preset names via JSON, eliminating legacy workarounds like static instrument definition files.

Understanding MIDI 2.0 Property Exchange

Property Exchange is a foundational feature of MIDI-CI, acting as a standardized application-layer protocol between MIDI 2.0 devices. Rather than relying on rigid, proprietary byte-streams, Property Exchange uses modern web-standard paradigms. It operates on a request-and-response model where devices send queries using JSON-formatted headers and payloads wrapped in Universal MIDI Packet (UMP) System Exclusive (SysEx) containers.

The Shift to JSON Payloads

Historically, DAWs required manually maintained XML, text, or proprietary patch maps (such as .midnam or .ins files) to display the patch names of external synthesizers. MIDI 2.0 replaces this workflow by using JSON (JavaScript Object Notation).

JSON provides a lightweight, human-readable, and machine-parsable format that allows complex data hierarchies—such as sound categories, banks, and preset names—to be modeled natively. Because JSON schemas are standardized by the MIDI Manufacturers Association (MMA) and AMEI, both controllers and sound generators share a common vocabulary for describing patches.

The Patch Retrieval Workflow

The exchange of patch names between an initiator (such as a DAW or hardware controller) and a responder (such as a sound module) follows a structured sequence:

1. Inquiry and Discovery: The initiator sends a MIDI-CI Inquiry to discover the device's capabilities. Once Property Exchange support is confirmed, the initiator queries the device's resource list.
2. Resource Request: The initiator issues a getPropertyData request specifying a patch-related resource, typically named ProgramList or ResourceList.
3. Chunking and Transport: If the patch list is large, the responder fragments the JSON payload across multiple Universal MIDI Packets using Property Exchange chunking mechanisms.
4. Delivery and Parsing: The responder sends a getPropertyDataReply containing the complete or assembled JSON object, which the initiator parses to populate its user interface.

Structure of JSON Patch Data

The JSON data returned by the sound generator defines how Bank Select (MSB and LSB) and Program Change values map to human-readable names. A typical payload contains structured arrays defining program hierarchy:

{
  "resource": "ProgramList",
  "bankList": [
    {
      "bankMSB": 0,
      "bankLSB": 0,
      "name": "Factory Lead",
      "programList": [
        { "program": 0, "name": "Analog Saw Lead" },
        { "program": 1, "name": "Poly Pulse 80s" },
        { "program": 2, "name": "Modular Sync" }
      ]
    },
    {
      "bankMSB": 0,
      "bankLSB": 1,
      "name": "Factory Bass",
      "programList": [
        { "program": 0, "name": "Deep Sub Bass" },
        { "program": 1, "name": "Acid Resonant Bass" }
      ]
    }
  ]
}

In addition to basic names and program numbers, the schema allows devices to include metadata such as patch author, sound categories, tags, and whether a preset is factory-locked or user-editable.

Real-Time Synchronization

MIDI 2.0 Property Exchange also supports publish/subscribe notifications. If a musician edits a patch name or saves a new preset directly on a synthesizer's hardware panel, the synth can send a Property Exchange set or subscription update containing the updated JSON fragment to the connected DAW. The DAW updates its track inspector instantly, ensuring the software environment remains perfectly synchronized with the hardware state.