Every MPE player has run into a version of this problem. You record a take with fluid per-note pitch bend and pressure, it sounds right, you save the project — and when you export it as a Standard MIDI File to hand to someone else, what comes back is a coarse, stepped approximation of what you played.
That is not a bug in your DAW. It is a limitation of a file format designed in 1988 for 7-bit data. The MIDI Association's MIDI Clip File Specification (M2-116-U v1.0) is the fix, and it is now published.
Why SMF Was Always Going to Lose Your Data
Standard MIDI Files store serialised MIDI 1.0 byte streams. That was a reasonable choice when the messages being stored were themselves 7-bit. But MPE performance data is not comfortable inside that envelope even in MIDI 1.0 — it works by spreading notes across channels and using channel-wide messages as per-note ones, which is a clever workaround rather than a native representation.
MIDI 2.0 removes the need for the workaround. Channel Voice messages carry 16-bit note velocity, 32-bit controller data, 32-bit pitch bend, 32-bit poly pressure, and genuine Per-Note Controllers that do not need a channel each. Parameter resolution goes from 128 steps to roughly 4.2 billion.
None of that fits in a byte stream built for 128 steps. Storing MIDI 2.0 data in an SMF file means downscaling it — which is exactly the flattening problem, formalised.
What a MIDI Clip File Does Differently
The MIDI Clip format stores Universal MIDI Packets directly, aligned as 32-bit words, rather than reconstructing them from a serialised byte stream. That is the whole idea, and its consequences are specific:
- Native storage of UMP message words, 32-bit aligned
- Preservation of Per-Note Controllers — no channel-rotation gymnastics required to reconstruct which controller belonged to which note
- Retention of Attribute Type and Attribute Data fields, including the articulation data used by the Orchestral Articulation Profile
- Compatibility with Group and Function Block addressing
- Full-resolution controller values retained at 16-bit or 32-bit precision
Because message boundaries and field widths stay intact, there is no ambiguity introduced by byte-stream reconstruction and no dependence on running status. What was transmitted is what gets stored, and what gets stored is what plays back.
For an MPE player, the practical translation is this: the shape of a bend, the curve of a pressure swell, and the relationship between them survive a round trip through a file.
The SMF2 Container
Sitting above the clip format is the SMF2 Container File Format, still being finalised. Rather than replacing Standard MIDI Files outright, SMF2 is a container that can encapsulate multiple data representations inside one structure — MIDI Clip data, structured metadata sections, extensibility for future data types, and coexistence strategies for MIDI 1.0 content where it is still needed.
The architecture separates container responsibilities from message semantics, which is the design decision that makes the whole thing survivable long-term. Paul Walmsley of the Steinberg Dorico team is developing open-source software implementing the container format, following the same pattern as the MIDI-CI Helper effort.
The MIDI-CI Helper, and Why It Matters Here
That helper deserves a mention, because it is the piece that determines whether any of this reaches players. Apple (Audio Units), Avid (AAX), Bitwig (CLAP) and Steinberg (VST) — alongside JUCE, the framework behind a large share of the plugins you own — are collaborating on open-source software that lets plugin developers interface with MIDI 2.0 gear without deep knowledge of MIDI 2.0 or MIDI-CI.
The DAW working group's software examines incoming MIDI 2.0 messages, extracts what a plugin needs to support Profiles including the MPE Profile, the Piano Profile and Orchestral Articulation, and translates them into the native plugin formats developers already handle. The stated goal is minimal development cost for MIDI 2.0 support.
That is the realistic path by which high-resolution per-note data ends up in the plugins MPE players actually use. Specifications alone do not move an ecosystem; a library that removes the implementation cost might.
What This Means in Practice, and When
Be clear-eyed about timelines. A published specification is not shipping software. What exists today is the format definition; what does not yet exist widely is DAW export, DAW import, or plugin-side handling of the results.
But the direction is consistent and the groundwork is unusually thorough. High-resolution Channel Voice messages provide the precision. MIDI-CI provides the negotiation. Profiles provide the semantic agreement about what messages mean. MIDI Clip and SMF2 provide interchange between different DAWs. Each piece is only useful with the others, which is presumably why they have been developed in parallel rather than sequentially.
For MPE players specifically, the file-format layer is the one that has been missing longest. Real-time performance has been solved for years — controllers send it, DAWs receive it, plugins respond. What has not been solved is what happens when the performance leaves your session: sending a take to a collaborator, archiving a project you will reopen in five years, moving a part between DAWs. Those workflows have quietly been where expression goes to die.
If you want to read the specifications directly, the MIDI Clip File Specification and the Universal MIDI Packet and MIDI 2.0 Protocol Specification are both published, as is the February 2026 state-of-MIDI-2.0 overview that ties the pieces together. If you would rather understand the negotiation layer first, our explainer on what MIDI 2.0 Property Exchange means for MPE is a shorter starting point.
Sources: MIDI.org