Logic Pro’s MIDI 2.0 Story
Logic Pro is Apple’s flagship DAW, and on paper it supports MIDI 2.0. Auto-mapping via Property Exchange, 32-bit velocity, the works. The marketing is convincing.
The reality, though, is a lot more limited. Stable MIDI-CI Property Exchange sessions are rare in the wild. KORG KeyStage integration sometimes works better when a third-party app handles it directly than when Apple’s own stack is in the loop.
Building MIDI2Kit forced me to dig into why. What I found: CoreMIDI itself hasn’t finished implementing the upper layers of MIDI 2.0. Logic Pro is sitting on an incomplete foundation.
The Evidence in CoreMIDI
The clearest signal is Apple’s own MIDI-CI participant — the node registered at 0x11 0x00 0x00. I wrote about it in detail in the previous post, but the pattern tells a story on its own:
- It exists in
MIDICIDeviceManager— so it’s registered as a CI participant - It responds to Discovery — the protocol’s front door is implemented
- It silently ignores all PE requests — the actual functionality is missing (or locked away from third parties)
You can knock on the door, and someone answers. But they won’t let you in.
MIDIUMPMutableEndpoint’s function block registration is the same story. On macOS 15, all 16 parameter combinations threw errors. On macOS 26.4, the errors disappeared — but only 1 of 16 combinations actually works. The other 15 fail silently: no error returned, but the function block simply never shows up in MIDIUMPEndpointManager.
The UMP receive path is suspect too. Opening a port with MIDIInputPortCreateWithProtocol(._2_0) and monitoring for 10 seconds yields nothing — zero UMP packets, zero Data 64 SysEx7 packets. Without external hardware connected I couldn’t be sure, but whether CoreMIDI’s internal CI SysEx even routes through the UMP path is unclear.
Here’s the thing: these APIs exist in the macOS 15 SDK headers. They’re just absent from every release note and WWDC session. Apple’s implicit message seems to be: not yet, not for you.
Logic Pro Sits on Top of CoreMIDI
This matters because Logic Pro is built on CoreMIDI. If CoreMIDI’s MIDI-CI and PE implementation is incomplete, Logic Pro can’t deliver complete MIDI 2.0 support — not without building its own parallel protocol stack from scratch.
CoreMIDI works well as a transport layer. UMP packet send/receive is solid. But the protocol work above transport — MIDI-CI Discovery management, PE transaction handling, device capability negotiation — that infrastructure isn’t there yet.
Maybe Logic Pro has its own internal implementation. But the fact that Apple’s own CI node won’t respond to PE requests tells us that at the OS level, this is still a construction zone.
Meanwhile, KORG Ships Working PE
KORG KeyStage paired with KORG Module Pro: MIDI-CI Discovery works, Property Exchange works, sound names appear on the KeyStage LCD, parameters map to hardware knobs, program changes flip through sounds. It’s everything MIDI 2.0 promised, actually delivered.
So why can KORG do this when Apple hasn’t?
They Own Both Sides
KORG builds the KeyStage (hardware) and Module Pro (software) in-house. They own the code on both ends of the connection. When one side needs to change, they can change the other to match.
This isn’t “we implemented the spec and it just worked.” It’s closer to “we tuned both sides until KeyStage and Module Pro talked to each other reliably.” The existence of proprietary resources like X-ProgramEdit and X-ParameterList is proof of this — they extended the protocol beyond the spec specifically for communication between their own products. That’s not how you implement an open standard. That’s how you ship a working product.
The Knowledge That Never Makes It Into the Spec
KORG, Roland, Yamaha, and Apple all participate in the MMA (MIDI Manufacturers Association) where MIDI 2.0 is developed. They sit in the same rooms and discuss the same drafts.
But there’s implementation knowledge that never makes it into any published document:
- Whether to use Mcoded7 encoding or not
- Whether
canGet/canSetshould be a boolean or a string - That Discovery re-sends need a 200ms gap or devices get confused
- That PE Notify echo-back has to be suppressed to prevent LCD freezes
None of that is in the spec. KORG’s keyboard talks reliably to KORG’s app because the same team — or teams that talk to each other constantly — knows both sides of the implementation.
I suspect MMA member companies share implementation know-how informally at spec sessions. Hardware manufacturers comparing notes on edge cases, telling each other “here’s how we handle this timing issue” — that kind of thing happens. It’s natural and probably expected. It just doesn’t happen where anyone outside the room can hear it.
Third Parties Are Left Outside
That’s the problem. The implementation knowledge doesn’t reach independent developers.
Every piece of KORG-specific behavior I discovered building MIDI2Kit came from SysEx sniffing — intercepting raw MIDI traffic and reverse-engineering the protocol. Zero information came from published documentation. The manufacturerName gating, the X-ProgramEdit format, the Initiator-only constraint, the Discovery re-send timing, the PE Notify echo-back avoidance — all of it, reverse-engineered.
Apple might be in a similar position. CoreMIDI’s half-finished MIDI-CI implementation could reflect exactly how hard it is to build upper protocol layers without tight coordination with the hardware manufacturers on the other end. They know the spec. They don’t know what every device does with it.
What “MIDI 2.0 Support” Actually Means in 2026
When a company claims “MIDI 2.0 support” right now, what they mean varies enormously:
| Level | What it means | Example |
|---|---|---|
| UMP Transport | Can send/receive UMP packets | CoreMIDI (macOS 11+) |
| High-Resolution Values | 32-bit velocity and CCs | Most new keyboards |
| MIDI-CI Discovery | Automatic device detection | KORG, Studio One |
| Property Exchange | JSON-based data exchange | KORG (same-vendor only, stable) |
| Full Interoperability | Cross-vendor PE works reliably | Nobody. Not yet. |
UMP transport is broadly implemented. But Property Exchange interoperability — even within a single manufacturer’s own ecosystem — still relies on proprietary extensions and internal knowledge. Cross-vendor PE that “just works” between arbitrary devices from different companies doesn’t exist yet.
Bridging the Gap from the Outside
MIDI2Kit is one attempt to close this from the third-party side.
KORG’s proprietary protocol was reverse-engineered and baked into the library. Apple’s unresponsive CI participant is auto-blacklisted so it doesn’t stall the handshake. BLE MIDI instability is handled with warm-up sequences and fallback logic.
This is one developer working against one manufacturer’s device set. I have no idea what Roland, Yamaha, or Native Instruments do differently — I don’t have their hardware. But the structural problem is the same everywhere: “what the spec doesn’t say” differs from vendor to vendor, and nobody is publishing those differences.
Until manufacturers open up their implementation details — or the spec gets detailed enough to eliminate the ambiguity — third-party developers will keep reverse-engineering, one device at a time. MIDI2Kit aims to be the place where that accumulated knowledge lives, so nobody else has to start from scratch.
Get Started with MIDI2Kit
The MIDI 2.0 library that handles the messy reality of real-world devices. Open source, MIT licensed.