MIDI 2.0 Property Exchange — what it unlocks for gamepads

For thirty years, every MIDI controller has shipped with the same pathological onboarding: plug it in, open MIDI Learn, click-twiddle-click-twiddle across every button. MIDI 2.0 Property Exchange kills this entire ritual. The controller hands the host a JSON document over Sysex8 that says "I have eighteen inputs, here are their names, here are sensible default mappings, here is which of my parameters supports 14-bit resolution". The host renders a real surface from that JSON. No more manual learn — this is the protocol detail that finally makes gamepads behave like real MIDI hardware.

The whole stack in one diagram

Property Exchange does not exist alone. It sits on top of MIDI-CI (Capability Inquiry), which sits on top of UMP (Universal MIDI Packets), which is the wire format. Roughly:

┌──────────────────────────────────────┐
│  Property Exchange — JSON-over-Sysex8 │   ← what we care about
├──────────────────────────────────────┤
│       MIDI-CI — discovery, MUIDs       │
├──────────────────────────────────────┤
│      UMP — 32-bit packet stream        │
├──────────────────────────────────────┤
│   USB MIDI 2.0 / virtual UMP endpoint  │
└──────────────────────────────────────┘

Both ends must speak MIDI 2.0 to use PE — that is the gate. On macOS 13+, CoreMIDI exposes UMP endpoints. On Windows, the MIDI Services API (Windows 11 24H2+) does the same. Linux ALSA Seq is shipping UMP support across kernel 6.5+. The full state of play is captured in the MIDI Association's MIDI 2.0 hub and we expand on it in our MIDI 2.0 gamepad roadmap.

What a DeviceInfo property looks like

The first useful thing the host pulls is DeviceInfo. This is a static JSON blob describing the device. For a DualSense bridge it looks like this:

{
  "manufacturer": "Aidxn Design",
  "family": "UniversalControllerMIDI",
  "model": "DualSenseBridge",
  "versionId": "1.4.2",
  "serialNumber": "U-DS-2026-0001",
  "manufacturerId": [0x00, 0x21, 0x49],
  "familyId": [0x00, 0x01],
  "modelId": [0x00, 0x07]
}

ChannelList — the mapping the DAW reads

The big one. ChannelList returns every input the device offers, what type it is, and the suggested mapping. The host renders this directly into a control-surface page.

{
  "channelList": [{
    "channel": 1,
    "title": "DualSense Gamepad",
    "controlList": [
      { "controlType": "cc", "ccNumber": 1, "title": "Left Stick X",
        "resolution": 14, "default": 64 },
      { "controlType": "cc", "ccNumber": 2, "title": "Left Stick Y",
        "resolution": 14, "default": 64 },
      { "controlType": "cc", "ccNumber": 7, "title": "L2 Trigger",
        "resolution": 7, "default": 0 },
      { "controlType": "note", "noteNumber": 60, "title": "Cross" },
      { "controlType": "note", "noteNumber": 61, "title": "Circle" },
      { "controlType": "rpn", "msb": 0, "lsb": 0, "title": "Pitch Bend Range" }
    ]
  }]
}

The DAW now knows that CC 1 is "Left Stick X" with 14-bit resolution and defaults to 64 at rest. It can label the surface, show a stick-shaped UI element, and warn the user if they try to bind something at 7-bit resolution. None of this was possible in MIDI 1.0 without a hand-rolled SysEx dialect — which is exactly the problem PE solves. The deep dive on legacy SysEx is in our SysEx commands post.

Property Exchange capabilities table

Property	Direction	What it does	Gamepad use
DeviceInfo	Device → Host	Identity + version	Tell host "I'm a DualSense Bridge v1.4.2"
ChannelList	Device → Host	Per-channel control map	Auto-populate the surface UI
JSONSchema	Device → Host	Validate other PE responses	Strict type-checking
ProgramList	Device → Host	Saved presets	List user-saved mappings
StateList	Both	Save/restore session state	Push current preset between sessions
X-AdaptiveTrigger (vendor)	Host → Device	Trigger feedback config	Set L2/R2 resistance from a DAW

Profiles — the higher-level shortcut

PE is paired with MIDI 2.0 Profiles. A Profile is a published agreement: "if I claim to support Profile X, then channels 1–8 mean these things by default". For gamepads, the proposed "Gamepad MIDI Bridge" Profile defines: face buttons on Notes 60–63, sticks on CCs 1–4, triggers on CCs 7–8, touchpad XY on CCs 16–17. A DAW that recognises the Profile lights up a matching control surface page the instant the device connects. The user does nothing. This is the dream of plug-and-play for the first time in MIDI history.

What the wire looks like

PE messages are serialised as Sysex8 (8-bit payload, not the 7-bit Sysex of MIDI 1.0). The JSON body is chunked across multiple Sysex8 packets if it exceeds the per-packet limit. Roughly:

F0 7E [device-id] 0D [sub-id-2] [muid] [request-id]
[json-header-length] [json-header...]
[chunk-count] [chunk-index]
[body-length] [body...]
F7

Forty bytes of framing for "give me the channel list". The framing is verbose; the win is that you only do it once per session. The chunking lets you push a 30 KB mapping document across without losing UMP timing for note traffic — chunks interleave with regular MIDI on the same endpoint.

What this changes for users

• No more MIDI Learn for the default layout. Plug in, host shows a real surface. Users can still remap, but they start from a working baseline.
• Per-DAW Profiles. A "Logic transport" Profile, an "Ableton Session" Profile, a "Resolume VJ" Profile. The user picks one, the device reconfigures.
• 14-bit awareness. The DAW knows which CCs are high-resolution and treats them differently in automation lanes.
• Round-trip remaps. Open the bridge UI, change the touchpad CC from 16 to 32, push a PE notify, the DAW updates the surface immediately. No port re-scan.

Where the implementation is in 2026

Honest status: Logic Pro 11 ships full PE support. Cubase 13 supports DeviceInfo and ChannelList. Ableton Live 12.1 has partial UMP support but no PE yet. Bitwig is researching. Reaper has Lua hooks but no native PE. Universal Controller MIDI emits the full PE stack on macOS and Windows; if your DAW does not yet read it, the bridge falls back to MIDI 1.0 with sensible defaults. No regressions, just a better experience where the host is ready.

Property Exchange is the protocol detail that turns "MIDI" into something that feels like a modern peripheral bus. For gamepads — devices with twenty-plus inputs and a complex internal state — it is the difference between "annoying to set up" and "plug and play". The MIDI Association's gamble was that JSON-over-Sysex8 would carry the next decade of controller UX. It is right.