MIDI 2.0 is explicitly designed as an extension of MIDI 1.0: it preserves the core musical semantics (channels, notes, controllers, program changes, etc.) while modernizing how messages are packaged, negotiated, and expressed at high precision. It does not replace MIDI 1.0, and that translation compatibility is a high priority in MIDI 2.0’s design.
The “major benefits” of MIDI 2.0 cluster into two highly interdependent advances:
High-resolution MIDI 2.0 Channel Voice Messages MIDI jumps from 128 steps to roughly 4.2 billion steps for many controls, and 65,000 steps for velocity. This expands expressiveness and eliminates audible “stepping” in continuous controls and performance capture.
Profiles (enabled via MIDI-CI Profile Configuration) Profiles are standardized “behavior contracts” for specific device types or tasks. They allow devices to discover, negotiate, and enable a known interaction model—so “the same messages mean the same thing” across implementations, reducing manual mapping and guesswork. Profiles a set of rules for how a receiver responds to a chosen set of messages for a purpose/application to increase interoperability and reduce user configuration.
Underneath those two pillars, MIDI 2.0 relies on:
Universal MIDI Packet (UMP), a standardized container format intended to carry both MIDI 1.0 and MIDI 2.0 protocols in a transport-adaptable way.
MIDI-CI, a bidirectional capability negotiation architecture enabling devices to identify shared features (Profiles, Property Exchange, Process Inquiry) while protecting backward compatibility.
With finalized core specifications and Profile documents—including the Drum Note Mapping, the Note-On Orchestral Articulation and the Piano Profiles—MIDI 2.0 has transitioned from architectural vision to practical implementation.
More Profiles are on the way including Drums and multiple DAW control profiles as well as the SMF2 Container format.
Resolution expansion from MIDI 1.0 to MIDI 2.0 Channel Voice messages.
UMP is Universal
UMP stands for Universal MIDI Packet. It is universal because it carries both MIDI 1.0 and MIDI 2.0 and because all future MIDI transports will be based on UMP.
Universal MIDI Packet essentials
The UMP specification (co-published by the MIDI Association and the Association of Musical Electronics Industry) defines a packet family where messages are represented as fixed multiples of 32-bit words (32/64/96/128-bit messages, depending on message type). It also introduces higher-level endpoint structures (e.g., endpoint discovery/configuration mechanisms and Function Blocks) that support more scalable routing and device partitioning than the original MIDI 1.0 byte stream model.
The MIDI Association and AMEI have already adopted the USB MIDI 2.0 and UDP Network transports.
Work is underway on a BLE MIDI 2.0 transport and we want to push W3C to adopt a Web MIDI 2.0 specification as well. MIDI 2.0 Channel Voice: what changes and why it matters
From 7-Bit to 32-Bit: The Resolution Story
MIDI 1.0 Channel Voice messages were primarily limited to 7-bit data (0–127), with 14-bit extensions for Pitch Bend and paired CC messages. While groundbreaking in 1983, this imposed quantization limits on modern sound engines capable of far higher internal precision.
These capabilities are defined in the MIDI 2.0 Specification Overview (M2-100) and the Bit Scaling and Resolution specification (M2-115), which ensures deterministic translation between 7-, 14-, 16-, and 32-bit domains.
MIDI 2.0 does not change the music — it enables more expressiveness.
MIDI 2.0 Protocol messages have extended data resolution for all Channel Voice messages, and adds “new properties” to some messages plus “new Channel Voice messages” enabling greatly improved Per-Note control and musical expression.
MIDI.org’s developer-facing “displaying high-resolution values” article quantifies the practical impact: parameter resolution increases from 128 steps to about 4.2 billion steps, with velocity at about 65 thousand steps, yielding smoother and more “analog” responsiveness.
Numeric resolutions and ranges (velocity, controllers, pressure, pitch)
Velocity: MIDI 2.0 Note On/Off encodes velocity with 16-bit resolution (0x0000 to 0xFFFF)
Continuous controllers (Control Change): MIDI 2.0 uses 32-bit values (0x00000000 to 0xFFFFFFFF) to represent controller state.
Pressure: MIDI 2.0 Channel Pressure and Poly Pressure are represented with 32-bit values (high-resolution aftertouch), supporting smoother control curves and better sensor capture than MIDI 1.0’s low-resolution representations.
Pitch: MIDI 2.0 Pitch Bend uses 32-bit values; the protocol also includes per-note pitch mechanisms (including Note On pitch attributes and per-note pitch controllers) that can support microtonal and per-note pitch behavior.
High-resolution per-note pressure supports modern expressive controllers.
Pitch bend
14-bit (0–16383)
32-bit
Much finer pitch curves; better vibrato/bends and editing.
Note On “attributes” as the bridge to Profiles
A key MIDI 2.0 design feature is that Note On/Off in MIDI 2.0 Channel Voice includes extra fields—commonly described as attributes—that can hold additional per-note information. This capability is explicitly central to the Orchestral Articulation Profile, which aims to encode articulations directly in the MIDI 2.0 Note On message using the Attribute Type and Attribute Data fields.
The UMP/MIDI 2.0 protocol spec also defines a translation rule: under default MIDI 1.0→MIDI 2.0 translation, Note On/Off Attribute Type defaults to “none” (0x00) unless a MIDI-CI Profile in effect specifies otherwise—making Profiles the formal mechanism that can change how note attributes are interpreted in a predictable, negotiated way.
Translation and “mixed MIDI 1.0 + MIDI 2.0” realities
The UMP spec explicitly lists classes of MIDI 2.0 Protocol messages with no MIDI 1.0 equivalent, including Relative Registered/Assignable Controllers and Per-Note Controllers/Management/Per-Note Pitch Bend; default translation therefore cannot preserve these behaviors into MIDI 1.0-only environments.
MIDI 2.0 products can ship with different feature sets: some devices implement MIDI-CI Profiles/Property Exchange and can operate over MIDI 1.0 transports (including 5-pin DIN), while true high-resolution MIDI 2.0 Channel Voice may depend on OS/stack support and compatible endpoints.
MIDI-CI: Negotiated Interoperability
MIDI-CI (M2-101) enables device discovery, protocol negotiation, and Profile management. M2-102 defines common rules for MIDI-CI Profiles. Devices can inquire about supported Profiles, request details, and enable or disable them dynamically.
MIDI-CI and how Profiles are defined, discovered, negotiated, and enabled
MIDI-CI discovery and negotiation at a systems level
MIDI-CI is the mechanism that allows MIDI to expand with new features while protecting backward compatibility: it “separates older MIDI products from newer products,” uses query/response to identify supported capabilities, and then negotiates/auto-configures common features—explicitly requiring bidirectional communication.
This Initiator/Responder terminology is used throughout the MIDI 2.0 specification ecosystem and is essential to Profile negotiation and device role expectations.
What a Profile is, and why it is a core MIDI 2.0 benefit
A Profile is “a defined set of rules for how a MIDI receiver device implementing the Profile shall respond to a chosen set of MIDI messages” for a purpose/application.
The Common Rules for MIDI-CI Profiles spec (official, co-published) provides a strong teaching argument: pre-MIDI 2.0 approaches like General MIDI had a “GM On” message but lacked a bidirectional confirmation mechanism; MIDI-CI Profiles leverage 2-way communication so the sender can know the receiver will interpret messages as the Profile defines.
“Common Rules for MIDI-CI Profiles” page also states that two devices conforming to the same Profile generally have greater interoperability and require less manual configuration from users.
Profile Enabled Report (Responder confirms enabled state; from this point, message semantics are defined by the Profile). The Piano Profile
Discovery (MIDI-CI connection established; device capabilities can be queried).
Profile Inquiry (Initiator asks what Profiles the Responder supports; Responder replies with enabled vs disabled supported Profiles).
Optional Profile Details (Initiator requests configuration details, especially important for multi-channel or Function Block Profiles).
Set Profile On (Initiator requests enabling the Profile, often at a requested “level” of support).
Profile IDs and levels
The Common Rules for Profiles spec defines a 5-byte Profile ID scheme and also defines the idea of Profile Levels (e.g., minimum required vs extended feature sets).
Profile families:
This table compares what several of the key Profiles that The MIDI Association focused on at the 2026 NAMM show.
Dimension
Piano Profile
Drums (Default Drum Note Map + Drum Performance)
DAW Control Profiles
Orchestral Articulation Profile
Primary purpose
Standardize piano velocity & pedal curves + registered controllers for piano performance.
Default note-number drum map (62 sounds)
Drum Performance standardizes expressive e‑drum features that were vendor-specific.
Replace proprietary DAW control protocols with modular Profiles for transport/location, dynamic controls, mixing.
Encode articulation in MIDI 2.0 Note On attributes; supports articulation equivalence across eight instrument categories.
Key message/attribute surfaces
MIDI 2.0 Registered Controllers (semantic set for piano params); curve definitions. Controller numbers and curve formulas: unspecified.
Default map uses Note Number → drum sound mapping
Drum Performance message set
Functional scope defined (transport, markers, displays). Includes Function Block and single-channel profiles
Explicitly uses MIDI 2.0 Note On Attribute Type/Data fields;
Resolution dependencies
Strongly benefits from 16-bit velocity and high-resolution controllers (expressive piano feel).
Default map is semantic, not resolution-driven;
Drum Performance requires MIDI 2.0
Benefits from high-resolution controls for smooth automation; exact requirements
Depends on Note On attributes and may use MIDI 2.0 controllers/per-note controllers (per intro PDF).
Negotiation steps
MIDI-CI Profile Inquiry → Set On → Enabled; Single-channel profile).
“Play here, sound/feel similarly there” via standardized curves/controls.
Drum clips transfer without remapping; expressive kit behaviors become cross-vendor without proprietary SysEx.
Controller portability across DAWs via standard modules.
Articulations remain meaningful when swapping libraries/instruments; easier copying/layering of orchestrated passages.
The Piano Profile
The Piano Profile standardizes interpretation of velocity curves, pedal behaviors (sustain, soft, sostenuto), and registered controllers for piano-focused devices. When negotiated via MIDI-CI, controllers and sound engines share a common behavioral contract.
This improves cross-manufacturer consistency between digital pianos, software instruments, controllers, and MIDI-enabled acoustic systems.
The piano is arguably the most important musical instrument in Western music traditions. It is essential to all styles of music from classical to jazz to pop.
This Piano Profile is intended for use on various types of MIDI Devices including:
Digital Pianos
Acoustic Pianos with mechanical key mechanisms driven by MIDI
Tone Generators (both hardware and software) which emulate an acoustic piano, without a keyboard
Acoustic Pianos with mechanical key mechanisms driven by MIDI and which also have a Tone Generator which emulates an acoustic piano
MIDI controller keyboards that send MIDI messages (without built in sounds and often used with a
software piano plugin)
The goal is a Piano Profile that defines the MIDI messages and bi-directional MIDI-CI communication necessary to allow the performance of an acoustic piano piece on one device that supports the Piano Profile to be accurately rendered on any other device which also supports the Profile.
The Piano Profile also details what information needs to be included in a Standard MIDI File (SMF2) and the mechanisms needed to accurately reproduce a piano performance from a file.
The Piano Profile addresses the following use cases:
Piano + tone generator (historically the most typical MIDI 1.0 use case and probably also in MIDI 2.0)
Online live broadcasting of piano performances
Online lessons with a teacher and student
MIDI Streaming of recorded piano performances
Music production (use of the Piano Profile with DAWs)
SMF Online sales
This Profile uses the mechanisms defined in MIDI-CI and the Common Rules for Profiles. The Piano Profile defines specific MIDI messages for interoperability between pianos which conform to the Profile, whether they are using the MIDI 1.0 Protocol or MIDI 2.0 Protocol.
Features of the Profile include:
Default Note On Velocity Curve definition
Pedaling/curves: half-pedaling, continuous sustain, sostenuto, sordino, una cord
A clearly defined response to a specifically chosen set of Control Change and Registered Controller. messages
Some new Registered Controllers (RC) (or RPN in MIDI 1.0 Protocol) for piano-specific functions
High resolution velocity (MIDI 2.0 Protocol only)
Expectation of tuning:
Recognition of stretched nature of acoustic pianos
Optional selection of Just Intonation, Mean Tone, Equal temperament etc.
MIDI 2.0 Drum Profiles: Formalizing Note Maps and Expressive Behavior
The MIDI 2.0 Drum Profiles establish a standardized and negotiable framework for electronic percussion interoperability. Defined within the MIDI-CI architecture (M2-101) and governed by the Common Rules for MIDI-CI Profiles (M2-102), these Profiles formalize both percussion note assignments and expressive drum performance semantics.
Layered structure of Drum Profiles.
The Default Drum Note Map Profile
The M2-125 Default Drum Note Map Profile specifies a standardized mapping between MIDI Note Numbers and defined percussion instruments. This mapping reflects long-established industry practice derived from General MIDI, but in MIDI 2.0 it is no longer assumed—it is explicitly declared and enabled via MIDI-CI Profile negotiation.
When the Default Drum Note Map Profile is supported and set to “On,” both Initiator and Responder devices agree to the defined Note Number assignments for core percussion sounds (e.g., kick, snare, hi-hats, toms, cymbals). Because Profile enablement is negotiated, devices can reliably exchange drum sequences with deterministic note-to-sound correspondence, eliminating ambiguity that previously existed when note maps were implementation-dependent.
MIDI-CI Drum Profile (Extended Drum Behavior) – Currently under development
Beyond static note mapping, the broader MIDI-CI Drum Profile specification provides a structured mechanism for negotiating drum-specific expressive capabilities. This includes behaviors historically implemented via proprietary System Exclusive messages, such as cymbal choke detection, positional sensing, or other performance-specific articulation controls.
Class Rules for Each Note Number
The MIDI-CI Profile for Drums specification assigns Classes of drum, cymbals, or percussion instrument type to each MIDI Note Number. Note Numbers are defined has having one of two possible Types of Class Assignments:
Default: The specification defines a core set of Note Numbers with fixed Classes. For example, the sound that is played on Note Number 38 is always one which fills the role of the Snare Class.
Assignable: Some Note Number do not have a predefined Class.
Instruments in a Device are sorted into Classes.
Class
Notes, Examples
Other
Any sound which does not naturally belong to any of the Classes
Kick / Bass Drum
Snare
Tom
Hi-hat
Cymbal
(other than Hi-hat)
Perc-Idiophone
Perc-Membranophone
Sound FX
Prerecorded Loop
Reserved
Instrument and Sound
Devices which conform to the Profile can assign any sound to the Instrument on that Note Number, if the Device designer decides that the sound generally fits the musical role of the Class for that Note Number.
Discovery: MIDI-CI Profile Specific Data
A discovery mechanism uses MIDI-CI Profile Specific Data messages for a Sender to get the Class and Instrument Name for each Note Number in a Receiver.
Performance
Notes are controlled by a MIDI 2.0 Protocol Note On message with Attribute data describing the Gesture Type and Distance fromm Center, plus a set of Per-Note Controllers. This is generally a note caused by Striking a drum or cymbal as a single, momentary occurrence. The impact of the strike excites the instrument to generate sound.
Gesture Type
The Gesture Type field declares how the Note is being played.
Table 9 Gesture Type Values
Gesture
Comments
Hi-hat Pedal
For Hi-hat Only*. Distance from Center may be ignored.
Normal Strike
On the primary playing surface, using Distance from Center
Rim Shot
Distance from Center = the position of end of the stick on the primary playing surface
Cross Stick
Distance from Center = the position of end of the stick on the primary playing surface
Rim Click
Sender should set Distance from Center to 0xFFF. Receiver may ignore Distance from Center value.
reserved
Distance from Center
0%, Center of the Instrument
100%, Outer Edge/Rim of the Instrument
A field declares Distance from the Center of the striking location on the Instrument at the moment of the Note On message. The value declares distance from center to the outer edge of the Instrument, where the minimum value represents the center of the Instrument, and the maximum value represents the outer edge or rim of the Instrument. The value is applied as a range from 0% to 100% regardless of actual distance and applied to a playing surface of any shape.
Alternatively, Note On messages with Attribute Data may be used plus a set of Per-Note Controllers. This is generally a note caused by Motion across the surface of a drum or cymbal which excites the instrument to generate sound. A typical example is using brushes on a snare drum.
Through MIDI-CI Profile Inquiry and Profile Details exchange, devices can determine supported drum features, enable the Profile, and operate using standardized semantics rather than manufacturer-specific conventions. This aligns electronic drum systems with the core MIDI 2.0 design principle: negotiated interoperability instead of implicit assumption.
With M2-125 and the MIDI-CI Profile for Drums, percussion interoperability moves from convention-based compatibility to formally negotiated behavior.
Together, these Drum Profiles ensure that rhythmic performance data—whether generated by electronic drum kits, drum machines, controllers, or DAW-based instruments—translates predictably across devices. By combining explicit Default Drum Note Map assignments with negotiable expressive extensions, MIDI 2.0 provides a scalable foundation for the next generation of electronic percussion systems.
Drum Profiles move electronic percussion from “mostly compatible” to fully negotiated interoperability.
DAW Control Profiles
DAW Control Profiles define modular, negotiated standards for transport control, marker management, dynamic parameter mapping, and plugin control. These Profiles replace legacy proprietary control layers with MIDI-CI-based negotiation.
DAW Control Profile negotiation and dynamic mapping.
There are three DAW Profiles planned and being worked on in The MIDI Association.
A Function Block Transport Control and Location Profile defining transport control, record arm, cycle markers, and punch in/out points.
A DAW control surface enables the transport/location Profile on a DAW integration layer, after which transport constraints and location controls behave consistently across controllers and DAWs that implement the Profile.
A Single Channel Dynamic Control Profile, describing dynamic controls as a set of controls affecting remote parameters (often plugins or tone generators), where controlled parameter sets can change across patches/focus.
Dynamic controls support the common workflow where a set of physical knobs is reused to control “the most relevant parameters” of the currently focused plugin/track, but with a standardized mechanism rather than bespoke mappings.
A Function Block Mixing Profile
The MIDI -CI Helper – open source software to allow plugins to Support MIDI 2.0
The MIDI Association member companies that develop plugin formats – Apple (Audio Units), Avid (AAX), Bitwig (CLAP) and Steinberg (VST) are working together to develop open-source software that will enable plugin developers to quickly and easily interface with external MIDI gear without the need for any in depth knowledge of MIDI 2.0 or MIDI-CI. Another MIDI Association member supporting this effort is JUCE – the most widely used framework for audio application and plug-in development.
The MIDI Association DAW working group is creating open source software that will look at MIDI 2.0 messages from external devices, extract the information the plugin needs to support Profiles like the Orchestral Articulation, MPE and Piano profiles and translate those MIDI messages into the native plug formats that plugins already understand.
By utilizing this open source software, plugin companies can start supporting MIDI 2.0 external devices with minimal development costs.
Orchestral Articulation Profile (M2-123)
The MIDI-CI Profile for Note On Selection of Orchestral Articulation (M2-123) provides a consistent way to encode articulation information directly in the MIDI 2.0 Note On message (using Attribute Type and Attribute Data), supporting articulation equivalence across eight instrument categories so articulated passages can be copied to other tracks and played back with analogous articulations. This eliminates reliance on hidden keyswitch notes and preserves articulation semantics during editing.
Structure of a MIDI 2.0 Note On message with articulation attributes.
Articulations are no longer side-channel instructions — they are part of the note itself.
We will provide an update on the Audio Impressions library that supports the Orchestral Articulation Profile and was demoed at NAMM 2026 in a separate article soon.
MIDI 2.0 File Interchange: MIDI Clip Files and the SMF2 Container Format
MIDI 2.0 extends beyond real-time transport. With the publication of the MIDI Clip File Specification (M2-116-U v1.0)and the soon to be finished SMF2 Container File Format specification , the MIDI Association has defined a forward-looking architecture for storing, exchanging, and encapsulating MIDI 2.0 data—including Universal MIDI Packets (UMP), high-resolution Channel Voice messages, and Profile-related metadata.
Together, these specifications ensure that MIDI 2.0’s expanded resolution and negotiated behaviors are preserved not only in live transmission, but also in file-based workflows across DAWs, notation systems, embedded devices, and archival systems.
The MIDI 2.0 MIDI Clip File Specification (M2-116)
The MIDI Clip File Specification (M2-116-U v1.0) defines a file format for storing MIDI 2.0 musical data in a way that is aligned with the Universal MIDI Packet (UMP) architecture. Unlike Standard MIDI Files (SMF 1.0), which store serialized MIDI 1.0 byte streams, MIDI Clip files store structured UMP messages directly.
This distinction is fundamental. Because MIDI 2.0 Channel Voice Messages may contain 16-bit velocity values, 32-bit controller data, per-note controllers, and attribute fields, a byte-stream representation designed for 7-bit data is insufficient. The MIDI Clip format preserves full-resolution UMP messages without downscaling.
Native storage of UMP message words (32-bit aligned)
Support for MIDI 2.0 Channel Voice messages
Preservation of Per-Note Controllers
Retention of Attribute Type and Attribute Data (e.g., Orchestral Articulation Profile)
Compatibility with Group and Function Block addressing
By storing UMP data directly, MIDI Clip files maintain deterministic fidelity between recorded performance and playback—particularly important when high-resolution controller data or Profile-enabled behaviors are in use.
The MIDI Clip format preserves MIDI 2.0 data at full resolution—no downscaling, no reinterpretation.
Profiles and Metadata in MIDI Clip Files
MIDI 2.0 Profiles, negotiated via MIDI-CI (M2-101) and governed by the Common Rules for Profiles (M2-102), define standardized behavioral contracts between devices. In a file-based workflow, it is critical that Profile-dependent performance data remains semantically intact.
The MIDI Clip specification allows UMP messages that reflect Profile-enabled operation to be stored exactly as transmitted. For example:
Orchestral Articulation Profile (M2-123) Attribute Type and Attribute Data fields remain embedded in Note On messages
High-resolution controller values are preserved at 16-bit or 32-bit precision
This ensures that a MIDI 2.0 clip authored under a specific Profile context can be reproduced accurately when reopened in a compatible environment.
The SMF2 Container File Format
The SMF2 Container File Format builds upon the legacy Standard MIDI File concept while providing a structured container capable of encapsulating MIDI 2.0 data formats, including MIDI Clip files.
Rather than replacing SMF outright, SMF2 introduces a containerized approach that allows multiple data representations to coexist within a unified file structure. This enables backward compatibility strategies while supporting native MIDI 2.0 content.
Within the SMF2 container, MIDI Clip data can be stored as defined structured entities, maintaining UMP alignment and metadata integrity. This architecture supports:
Encapsulation of MIDI 2.0 Clip data
Structured metadata sections
Extensibility for future data types
Coexistence strategies with MIDI 1.0 data where required
By separating container responsibilities from message semantics, the SMF2 specification provides long-term scalability while preserving the deterministic properties of UMP-based data.
Paul Walmsley from the Steinberg Dorico team is developin open source software that implements the SMF2 container format which will make it easier for companies to implement the SMF2 specification in the same way the MIDI-CI helper will aid plug-in developers.
UMP Representation in File Storage
Universal MIDI Packets are defined as 32-bit words organized into fixed-length message formats (32, 64, 96, or 128 bits depending on message type). The MIDI Clip specification stores these words in aligned form, ensuring that message boundaries and field widths remain intact.
Avoiding ambiguity introduced by byte-stream reconstruction
In contrast to legacy SMF storage—where interpretation depends on running status and serialized byte reconstruction—the MIDI Clip approach ensures that stored data matches transmitted UMP structures directly.
Interoperability and Forward Compatibility
The combination of MIDI Clip files (M2-116) and the SMF2 Container format establishes a future-proof framework for MIDI 2.0 file interchange. High-resolution performance data, Profile semantics, and UMP structure are preserved without compromise.
At the same time, containerization strategies allow transitional workflows between MIDI 1.0 and MIDI 2.0 environments. This reflects a central design philosophy of MIDI 2.0: evolution without disruption.
MIDI 2.0 is not only a transport protocol—it is a complete data ecosystem spanning real-time messaging and file interchange.
Conclusion
With the publication of M2-116 (MIDI Clip File Specification) and the SMF2 Container File Format, MIDI 2.0 establishes a modern file-based architecture aligned with UMP, Profiles, and high-resolution Channel Voice messaging. These specifications ensure that the expressive capabilities of MIDI 2.0 are preserved not only in live performance, but also in creation, exchange, and archival workflows across the global music technology ecosystem.
The Combined Impact
High-resolution Channel Voice messages provide precision. MIDI-CI provides negotiation. Profiles provide semantic agreement. The MIDI-CI Helper allows pligin companies to support MIDI 2.0 without needing to deal with SysEx or even have a SysEx ID. The MIDI Clip and SMF2 Container format allow interchange between different DAWs.
Together, they ensure MIDI remains interoperable, extensible, and expressive for the next generation of musical innovation.
Conclusion
MIDI 2.0 does not replace MIDI 1.0 — it extends it. By increasing resolution and enabling negotiated Profiles, the MIDI Association has ensured that MIDI continues to evolve while preserving backward compatibility and cross-manufacturer interoperability.
