Logic Pro’s MIDI 2.0 Status
Logic Pro is Apple’s flagship DAW, and it claims MIDI 2.0 support. Property Exchange for auto-mapping, 32-bit velocity, the headline features. But the actual implementation is limited. Stable MIDI-CI Property Exchange sessions are rare in the wild. KORG KeyStage integration sometimes works better through third-party code than through Apple’s own stack.
Building MIDI2Kit forced me to look closely at what CoreMIDI actually does under the hood. What I found: CoreMIDI itself hasn’t finished implementing the upper layers of MIDI 2.0.
Evidence: CoreMIDI’s Incomplete State
The Apple-manufactured MIDI-CI participant (0x11 0x00 0x00) tells the whole story. As I detailed in a previous post:
- It exists in
MIDICIDeviceManager— so it’s registered as a CI participant - It responds to Discovery — the protocol’s front door is implemented
- It ignores all PE requests — the actual functionality is missing (or locked away from third parties)
MIDIUMPMutableEndpoint’s function block registration shows the same pattern. On macOS 15, all 16 parameter combinations threw errors. On macOS 26.4, the errors are gone, but only 1 of 16 combinations actually works. The other 15 fail silently — no error returned, but the function block simply doesn’t appear in MIDIUMPEndpointManager.
The UMP receive path is suspect too. Opening a port with MIDIInputPortCreateWithProtocol(._2_0) and monitoring for 10 seconds yields zero UMP packets, zero Data 64 SysEx7 packets. Without external devices connected, I couldn’t confirm whether CoreMIDI’s internal CI SysEx even routes through the UMP path.
These APIs exist in the macOS 15 SDK headers. They don’t appear in release notes or WWDC sessions. Apple seems to be saying: “not ready for public consumption yet.”
Logic Pro Sits on Top of CoreMIDI
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.
CoreMIDI works fine as a pipe. UMP packet send/receive is solid. But the protocol layers above transport — MIDI-CI Discovery management, PE transaction handling, device capability negotiation — those aren’t ready.
Logic Pro might have its own internal implementation of these layers. But the fact that Apple’s own CI node doesn’t respond to PE requests tells us that at the OS level, this is still under construction.
Meanwhile, KORG Ships Working PE
KORG KeyStage paired with KORG Module Pro: MIDI-CI Discovery works, Property Exchange works, sound names show up on the KeyStage LCD, parameters map to hardware knobs, program changes switch sounds. It’s the MIDI 2.0 promise, delivered.
Why can KORG do this when Apple can’t?
They Control Both Sides
KORG builds KeyStage (hardware) and Module Pro (software). They own the code on both ends. When one side needs adjustment, they can change the other to match.
This isn’t a case of “we implemented the spec and it just worked.” It’s closer to “we tuned both sides until KeyStage and Module talk to each other.” The existence of proprietary resources like X-ProgramEdit and X-ParameterList proves this — they added custom protocol extensions that aren’t in the MIDI 2.0 spec, designed for communication between their own products.
Shared Knowledge Between Manufacturers
KORG, Roland, Yamaha, and Apple all participate in the MMA (MIDI Manufacturers Association) where the MIDI 2.0 spec is developed. They sit in the same rooms, discuss the same drafts.
But there’s implementation knowledge that never makes it into the spec:
- Whether to use Mcoded7 encoding or not
- Whether
canGet/canSetshould be bool or string type - That Discovery re-sends need a 200ms gap
- That PE Notify echo-back must be suppressed to prevent LCD freezes
These details don’t appear in any published document. KORG’s keyboard talks to KORG’s app because the same team (or closely collaborating teams) knows both sides of the implementation.
It’s likely that MMA member companies share implementation know-how informally. Hardware manufacturers meeting at spec sessions, exchanging notes on “here’s how we handle this edge case” — this would be natural and expected.
Third Parties Are Left Out
The problem: this implementation knowledge doesn’t reach third-party developers.
Every piece of KORG-specific behavior I discovered while 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, Discovery re-send timing, PE Notify echo-back avoidance — all reverse-engineered.
Apple might be in a similar position. CoreMIDI’s half-finished MIDI-CI implementation could reflect the difficulty of building upper protocol layers without tight coordination with hardware manufacturers.
What “MIDI 2.0 Support” Actually Means in 2026
When a company says “MIDI 2.0 support” in 2026, 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 Interop | Cross-vendor PE works reliably | Nobody. Not yet. |
The bottom layer — UMP transport — is widely implemented. But Property Exchange interoperability, even within a single manufacturer’s ecosystem, still relies on proprietary extensions. Cross-vendor PE that “just works” doesn’t exist yet.
Bridging the Gap Ourselves
MIDI2Kit is one attempt to close this gap.
KORG’s proprietary protocol was reverse-engineered and integrated into the library. Apple’s unresponsive CI participant is auto-blacklisted. BLE MIDI instability is handled with warm-up sequences and fallback strategies.
This is one developer’s work against one manufacturer’s devices. I have no idea what Roland, Yamaha, or Native Instruments do differently. But the structural problem is the same everywhere: “things not written in the spec” differ from vendor to vendor.
Until manufacturers publish their implementation details — or the spec itself becomes detailed enough to eliminate 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 zero.
Get Started with MIDI2Kit
The MIDI 2.0 library that handles the messy reality of real-world devices. Open source, MIT licensed.