This article is to explain the benefits of MIDI 2.0 to people who use MIDI.
If you are a MIDI developer looking for the technical details about MIDI 2.0, go to this article updated to reflect the major updates published to the core MIDI 2.0 specs in June 2023.
The following movie explains the basics of MIDI 2.0 in simple language.
MIDI 2.0 Overview
Music is the universal language of human beings and MIDI is the universal digital language of music
Back in 1983, musical instrument companies that competed fiercely against one another nonetheless banded together to create a visionary specification—MIDI 1.0, the first universal Musical Instrument Digital Interface.
Nearly four decades on, it’s clear that MIDI was crafted so well that it has remained viable and relevant. Its ability to join computers, music, and the arts has become an essential part of live performance, recording, smartphones, and even stage lighting.
Now, MIDI 2.0 takes the specification even further, while retaining backward compatibility with the MIDI 1.0 gear and software already in use. MIDI 2.0 is the biggest advance in music technology in 4 decades. It offers many new features and improvements over MIDI 1.0, such as higher resolution, bidirectional communication, dynamic configuration, and enhanced expressiveness.
MIDI 2.0 Means Two-way MIDI Conversations
MIDI 1.0 messages went in one direction: from a transmitter to a receiver. MIDI 2.0 is bi-directional and changes MIDI from a monologue to a dialog. With the new MIDI-CI (Capability Inquiry) messages and UMP EndPoint Device Discovery Messages, MIDI 2.0 devices can talk to each other, and auto-configure themselves to work together.
They can also exchange information on functionality, which is key to backward compatibility—MIDI 2.0 gear can find out if a device doesn’t support MIDI 2.0, and then simply communicate using MIDI 1.0.
MIDI 2.0 Specs are mostly for MIDI developers, not MIDI users
If you are a MIDI user trying to read and make sense of many of the new MIDI 2.0 specs, MIDI 2.0 may seem really complicated.
Yes, it actually is more complicated because we have given hardware and software MIDI developers and operating system companies the ability to create bi-directional MIDI communications between devices and products.
MIDI 2.0 is much more like an API (application programming interface, a set of functions and procedures allowing the creation of applications that access the features or data of an operating system, application, or other service) than a simple one directional set of data messages like MIDI 1.0.
Just connect your MIDI gear exactly like you always have and then the operating systems, DAWs and MIDI applications take over and try to auto-configure themselves using MIDI 2.0.
If they can’t then they will work exactly like they do currently with MIDI 1.0.
If they do have mutual MIDI 2.0 features, then these auto-configuration mechanisms will work and set up your MIDI devices for you.
MIDI 2.0 works harder so you don’t have to.
Just Use MIDI
As you can see the only step that MIDI users really have to think about is Step 7 -Use MIDI
MIDI 2.0 expands MIDI to 256 Channels in 16 Groups so you will start to see applications and products that display Groups, but these are not so different than the 16 Ports in USB MIDI 1.0.
We have tried very hard to make it simple for MIDI users, but as any good developer will tell you – making it easy for users often makes more work for developers.
MIDI-CI Profile Configuration
At Music China 2023, there were a number of public presentations of recent MIDI specifications that the MIDI Association has been working on.
Joe Shang from Medeli who is on the MIDI Association Technical Standards board put it very well at the International MIDI Forum at Music China.
He said that with the recent updates published in June 2023, MIDI 2.0 had a strong skeleton, but now we need to put muscles on the bones. He also said that Profiles are the muscles we need to add.
He is right. This will be “The Year Of Profiles” for The MIDI Association.
We have now adopted 7 Profiles.
- MIDI-CI Profile for General MIDI 2 (GM2 Function Block Profile)
- MIDI-CI Profile for for General MIDI 2 Single Channel (GM2 Melody Channel)
- MIDI-CI Profile for Drawbar Organ Single Channel
- MIDI-CI Profile for Rotary Speaker Single Channel
- MIDI-CI Profile for MPE (Multi Channel)
- MIDI-CI Profile for Orchestral Articulation Single Channel
We also have completed the basic design of three more Profiles.
- MIDI-CI Profile for Orchestral Articulation Single Channel
- MIDI-CI Profile for Piano Single Channel
- MIDI-CI Profile for Camera Control Single Channel
At Music China and at the meeting we had at the same time at Microsoft office in Redmond, MIDI Association and AMEI members were talking about the UDP Network transport specification that we are working on and the need to Profiles for all sorts of Effects ( Chorus, Reverb, Phaser, Distortion, etc.), Electronic Drums, Wind Controllers and DAW control.
The MIDI 2.0 overview defined a defined sets of rules for how a MIDI device sends or responds to a specific set of MIDI messages to achieve a specific purpose or suit a specific application.
Advanced MIDI users might be familiar with manually “mapping” all the controllers from one device to another device to make them talk to each other. Most MIDI users are familiar with MIDI Learn.
If 2 devices agree to use a common Profile, MIDI-CI Profile Configuration can auto-configure the mappings. Two devices learn what their common capabilities are and then can auto-configure themselves to respond correctly to a whole set of MIDI messages.
MIDI gear can now have Profiles that can dynamically configure a device for a particular use case. If a control surface queries a device with a “mixer” Profile, then the controls will map to faders, panpots, and other mixer parameters. But with a “drawbar organ” Profile, that same control surface can map its controls automatically to virtual drawbars and other keyboard parameters—or map to dimmers if the profile is a lighting controller. This saves setup time, improves workflow, and eliminates tedious manual programming.
Actually General MIDI was an example of what a Profile could do.
GM was a defined set of responses to set of MIDI messages. But GM was done before the advent of the bi-directional communication enabled by MIDI-CI.
So in the MIDI 1.0 world, you sent out a GM On message, but you never knew if the device on the other side could actually respond to the message. There was no dialog to establish a connection and negotiate capabilities.
But bi-directional commmunication allows for much better negotiation of capabilities (MIDI -CI stands for Capabilities Inquiry after all).
One of the important things about Profiles is that they can negotiate a set of features like the number of Channels a Profile wants to use. Some Profiles like the Piano Profile are Single Channel Profiles and get turned on and used on any single channel you want.
Let’s use the MPE Profile as an example. MPE works great, but it has no bi-directional communication for negotiation.
With MIDI 2.0 using a mechanism called the Profile Details Inquiry message, two products can agree that they want to be in MPE Mode, agree on the number of channels that both devices can support, the number of dimensions of control that both devices support (Pitch Bend, Channel Pressure and a third dimension of control) and even if both devices support high resolution bi-polar controllers. Bi-directional negotiation just makes things work better automatically.
Let’s consider MIDI pianos. Pianos have a lot of characteristics in common and we can control those characteristics by a common set of MIDI messages. MIDI messages used by all pianos include Note On/Off and Sustain Pedal.
But when we brought all the companies that made different kinds of piano products together (digital piano makers like Kawai, Korg and Roland, companies like Yamaha and Steinway that make MIDI controlled acoustic pianos and softsynth companies like Synthogy that makes Ivory), we realized that each company had different velocity and sustain pedal response curves.
We decided that if we all agreed on a Piano Profile with an industry standard velocity and pedal curve, it would greatly enhance interoperability.
Orchestral Articulation is another great example. There are plenty of great orchestral libraries, but each company uses different MIDI messages to switch articulations. Some companies use notes on the bottom of the keyboard and some use CC messages. So we came up with way to put the actual articulation messages right into the expanded fields in the MIDI 2.0 Note On message.
The following video has a demonstration of how Profile Configuration works.
The MIDI Association adopted the first Profile in 2022, the Default Control Change Mapping Profile.
Many MIDI devices are very flexible in configuration to allow a wide variety of interaction between devices in various applications. However, when 2 devices are configured differently, there can be a mismatch that reduces interoperability.
This Default Control Change Mapping Profile defines how devices can be set to a default state, aligned with core definitions of MIDI 1.0 and MIDI 2.0. In particular, devices with this Profile enabled have the assignment of Control Change message destinations/functions set to common, default definitions.
Because there were less than 128 controllers in MIDI 1.0, even the most commonly used could be reassigned to other functions.
Turning on this Profile sets commonly used controllers such as Volume (CC7), Pan (CC-10) , Sustain (CC64), Cutoff (CC 74), Attack (CC73), Decay (CC75), Release (CC72), Reverb Depth (CC91) to their intended assignment.
The video above included a very early prototype of the Drawbar Organ Profile and Rotary Speaker Profile.
We have just finished videos for Music China. Here are short videos for:
MIDI-CI Property Exchange
Property Exchange is a set of System Exclusive messages that devices can use discover, get, and set many properties of MIDI devices. The properties that can be exchanged include device configuration settings, a list of patches with names and other meta data, a list of controllers and their destinations, and much more.
Property Exchange can allow for devices to auto map controllers, choose programs by name, change state and also provide visual editors to DAW’s without any prior knowledge of the device or specially crafted software. This means that Devices could work on Windows, Mac, Linux, IOS and Web Browsers and may provide tighter integrations with DAW’s and hardware controllers.
Property Exchange uses JSON inside of the System Exclusive messages. JSON (JavaScript Object Notation) is a human readable format for exchanging data sets. The use of JSON expands MIDI with a whole new area of potential capabilities.
The MIDI Association has completed and published the following Property Exchange Resources.
- Property_Exchange_Foundational_Resources
- Property_Exchange_Mode_Resources
- Property_Exchange_ProgramList_Resource
- Property_Exchange_Channel_Resources
- Property_Exchange_LocalOn_Resource
- Property_Exchange_MaxSysex8Streams_Resource
- Property_Exchange_Get_and_Set_Device_State
- Property_Exchange_StateList
- Property_Exchange_ExternalSync_Resource
- Property_Exchange_Controller_Resources
One of the most interesting of these PE specifications is Get and Set Device State which allows for an Initiator to send or receive Device State, or in other words, to capture a snapshot which might be sent back to the Device at a later time.
The primary goal of this application of Property Exchange is to GET the current memory of a MIDI Device. This allows a Digital Audio Workstation (DAW) or other Initiator to store the State of a Responder Device between closing and opening of a project. Before a DAW closes a project, it performs the GET inquiry and the target Device sends a REPLY with all data necessary to restore the current State at a later time. When the DAW reopens a project, the target Device can be restored to its prior State by sending an Inquiry: Set Property Data Message.
Data included in each State is decided by the manufacturer but typically might include the following properties (not an exhaustive list):
- Current Program
- All Program Parameters
- Mode: Single Patch, Multi, etc.
- Current Active MIDI Channel(s)
- Controller Mappings
- Samples and other binary data
- Effects
- Output Assignments
Essentially this will allow hardware devices to have the same amount of recallability as soft synths when using a DAW.
There are a number of MIDI Association companies who are actively working on implementing this MIDI 2.0 Property Exchange Resource.
MIDI-CI Process Inquiry
Version 1.2 of MIDI-CI introduces a new category of MIDI-CI, Process Inquiry, which allows one device to discover the current values of supported MIDI Messages in another device including: System Messages, Channel Controller Messages and Note Data Messages
Here some use cases:
- Query the current values of parameters which are settable by MIDI Controller messages.
- Query to find out which Program is currently active
- Query to find out the current song position of a sequence.
For Those Who Want To Go Deeper
In the previous version of this article, we provide some more technical details and we will retin them here for those who want to know more, but if you are satified with knowing what MIDI 2.0 can do for you, you can stop reading here.
MIDI Capability Inquiry (MIDI-CI) and UMP Discovery
To protect backwards compatibility in a MIDI environment with expanded features, devices need to confirm the capabilities of other connected devices. When 2 devices are connected to each other, they confirm each other’s capabilities before using expanded features. If both devices share support for the same expanded MIDI features they can agree to use those expanded MIDI features.
The additional capabilities that MIDI 2.0 brings to devices are enabled by MIDI-CI and by new UMP Device Discovery mechanisms.
New MIDI products that support MIDI-CI and UMP Discovery can be configured by devices communicating directly themselves. Users won’t have to spend as much time configuring the way products work together.
Both MIDI-CI and UMP Discovery share certain common features:
- They separate older MIDI products from newer products with new capabilities and provides a mechanism for two MIDI devices to understand which new capabilities are supported.
- They assume and require bidirectional communication. Once a bi-directional connection is established between devices, query and response messages define what capabilities each device has then negotiate or auto-configure to use those features that are common between the devices.
MIDI DATA FORMATS AND ADDRESSING
MIDI 1.0 BYTE STREAM DATA FORMAT
MIDI 1.0 originally defined a byte stream data format and a dedicated 5 pin DIN cable as the transport. When computers became part of the MIDI environment, various other transports were needed to carry the byte stream, including software connections between applications. What remained common at the heart of MIDI 1.0 was the byte stream data format.
The MIDI 1.0 Data Format defines the byte stream as a Status Byte followed by data bytes. Status bytes have the first bit set high. The number of data bytes is determined by the Status.
Addressing in MIDI 1.0 DATA FORMAT
The original MIDI 1.0 design had 16 channels. Back then synthesizers were analog synths with limited polyphony (4 to 6 Voices) that were only just starting to be controlled by microprocessors.
In MIDI 1.0 byte stream format, the value of the Status Byte of the message determines whether the message is a System Message or a Channel Voice Message. System Messages are addressed to the whole connection. Channel Voice Messages are addressed to any of 16 Channels.
Addressing in USB MIDI 1.0 DATA FORMAT
In 1999 when the USB MIDI 1.0 specification was adopted, USB added the concept of a multiple MIDI ports. You could have 16 ports each with its own 16 channels on a single USB connection.
The Universal MIDI Packet (UMP) Format
The Universal MIDI Packet (UMP) Format, introduced as part of MIDI 2.0, uses a packet-based data format instead of a byte stream. Packets can be 32 bits, 64 bits, 96 bits, or 128 bits in size.
This format, based on 32 bit words, is more friendly to modern processors and systems than the byte stream format of MIDI 1.0. It is well suited to transports and processing capabilities that are faster and more powerful than those when MIDI 1.0 was introduced in 1983.
More importantly, UMP can carry both MIDI 1.0 protocol and MIDI 2.0 protocol. It is called a Universal MIDI Packet because it handles both MIDI 1.0 and MIDI 2.0 and is planned to be used for all new transports defined by the MIDI Association including the already updated USB MIDI 2.0 specification and the Network Transport specification that we are currently working on.
Addressing in UMP FORMAT
The Universal MIDI Packet introduces an optional Group field for messages. Each Message Type is defined to be addressed with a Group or without a Group field (“Groupless”).
Channels, Groups and Groupless Messages in UMP
These mechanisms expand the addressing space beyond that of MIDI 1.0.
Groupless Messages are addressed to the whole connection. Other messages are addressed to a specific Group, either as a System message for that whole Group or to a specific Channel within that Group.
UMP continues this step by step expansion of MIDI capabilities while maintaining the ability to map back to MIDI products from 1983.
UMP carries 16 Groups of MIDI Messages, each Group containing an independent set of System Messages and 16 MIDI Channels. Therefore, a single connection using the Universal MIDI Packet carries up to 16 sets of System Messages and up to 256 Channels.
Each of the 16 Groups can carry either MIDI 1.0 Protocol or MIDI 2.0 Protocol. Therefore, a single connection can carry both protocols simultaneously. MIDI 1.0 Protocol and MIDI 2.0 Protocol messages cannot be mixed together within 1 Group.
Groups are slightly different than Ports, but for compatibility with legacy 5 PIN DIN, a single 16 channel Group in UMP can be easily mapped back to a 5 PIN DIN Port or to a Port in USB MIDI.
You will soon start to see applications which offer selection for Groups and Channels.
The newest specifications in June 2023 add the concept of Groupless Messages and Function Blocks.
Groupless Messages are used to discover details about a UMP Endpoint and its Function Blocks.
Some Groupless Messages are passed to operating systems and applications which use them to provide you with details of what functions exist in the MIDI products you have.
Now a MIDI Device can declare that Groups 1,2,3,and 4 are all used for a single function for 96 Channels (for example a mixer or a sequencer).
All of these decisions had to be made very carefully to ensure that everything would map back and work seamlessly with MIDI 1.0 products from 1983.
UMP Discovery
The UMP Format defines mechanisms for Devices to discover fundamental properties of other Devices to connect, communicate and address messages. Discoverable properties include:
1. Device Identifiers: Name, Manufacturer, Model, Version, and Product Instance Id (e.g. unique identifier).
2. Data Formats Supported: Version of UMP Format (necessary for expansion in the future), MIDI Protocols, and whether Jitter Reduction Timestamps can be used.
3. Device Topology: including which Groups are currently valid for transmitting and receiving messages and which Groups are available for MIDI-CI transactions.
These properties can be used for Devices to auto-configure through bidirectional transactions, thereby enabling the best connectivity between the Devices. These properties can also provide useful information to users for manual configuration.
UMP handles both MIDI 1.0 and MIDI 2.0 Protocols
MIDI 2.0 Protocol- Higher Resolution, More Controllers and Better Timing
The MIDI 2.0 Protocol uses the architecture of MIDI 1.0 Protocol to maintain backward compatibility and easy translation while offering expanded features.
- Extends the data resolution for all Channel Voice Messages.
- Makes some messages easier to use by aggregating combination messages into one atomic message.
- Adds new properties for several Channel Voice Messages.
- Adds several new Channel Voice Messages to provide increased Per-Note control and musical expression.
- Adds New data messages include System Exclusive 8 and Mixed Data Set. The System Exclusive 8 message is very similar to MIDI 1.0 System Exclusive but with 8-bit data format. The Mixed Data Set Message is used to transfer large data sets, including non-MIDI data.
- Keeps all System messages the same as in MIDI 1.0.
Expanded Resolution and Expanded Capabilities
This example of a MIDI 2.0 Protocol Note message shows the expansions beyond the MIDI 1.0 Protocol equivalent. The MIDI 2.0 Protocol Note On has higher resolution Velocity. The 2 new fields, Attribute Type and Attribute data field, provide space for additional data such as articulation or tuning details
Easier to Use: Registered Controllers (RPN) and Assignable Controllers (NRPN)
Creating and editing RPNs and NRPNs with MIDI 1.0 Protocol requires the use of compound messages. These can be confusing or difficult for both developers and users. MIDI 2.0 Protocol replaces RPN and NRPN compound messages with single messages. The new Registered Controllers and Assignable Controllers are much easier to use.
The MIDI 2.0 Protocol replaces RPN and NRPN with 16,384 Registered Controllers and 16,384 Assignable Controller that are as easy to use as Control Change messages.
Managing so many controllers might be cumbersome. Therefore, Registered Controllers are organized in 128 Banks, each Bank having 128 controllers. Assignable Controllers are also organized in 128 Banks, each Bank having 128 controllers.
Registered Controllers and Assignable Controllers support data values up to 32bits in resolution.
MIDI 2.0 Program Change Message
MIDI 2.0 Protocol combines the Program Change and Bank Select mechanism from MIDI 1.0 Protocol into one message. The MIDI 1.0 mechanism for selecting Banks and Programs requires sending three MIDI messages. MIDI 2.0 changes the mechanism by replicating the Banks Select and Program Change in one new MIDI 2.0 Program Change message. Banks and Programs in MIDI 2.0 translate directly to Banks and Programs in MIDI 1.0.
Built for the Future
MIDI 1.0 is not being replaced. Rather it is being extended and is expected to continue, well integrated with the new MIDI 2.0 environment. It is part of the Universal MIDI Packet, the fundamental MIDI data format.
In the meantime, MIDI 1.0 works really well. In fact, MIDI 2.0 is just more MIDI. As new features arrive on new instruments, they will work with existing devices and system. The same is true for the long list of other additions made to MIDI since 1983. MIDI 2.0 is just part of the evolution of MIDI that has gone on for 36 years. The step by step evolution continues.
Many MIDI devices will not need any of the new features of MIDI 2.0 in order to perform all their functions. Some devices will continue to use the MIDI 1.0 Protocol while using other extensions of MIDI 2.0, such as Profile Configuration, Property Exchange or Process Inquiry.
MIDI 2.0 is the result of a global, decade-long development effort.
Unlike MIDI 1.0, which was initially tied to a specific hardware implementation, a new Universal MIDI Packet format makes it easy to implement MIDI 2.0 on any digital transport. MIDI 2.0 already runs on USB, Analog Devices A2b Bus and we are working on an network transport spec.
To enable future applications that we can’t envision today, there’s ample space reserved for brand-new MIDI messages.
Further development of the MIDI specification, as well as safeguards to ensure future compatibility and growth, will continue to be managed by the MIDI Manufacturers Association working in close cooperation with the Association of Musical Electronics Industry (AMEI), the Japanese trade association that oversees the MIDI specification in Japan.
MIDI will continue to serve musicians, DJs, producers, educators, artists, and hobbyists—anyone who creates, performs, learns, and shares music and artistic works—in the decades to come.
MIDI 2.0 FAQs
We have been monitoring the comments on a number of websites and wanted to provide some FAQs about MIDI 2.0 as well as videos of some requested MIDI 2.0 features.
Will MIDI 2.0 devices need to use a new connector or cable?
No, MIDI 2.0 is a transport agnostic protocol.
- Transport- To transfer or convey from one place to another
- Agnostic- designed to be compatible with different devices
- Protocol-a set of conventions governing the treatment and especially the formatting of data in an electronic communications system
That’s engineering speak for MIDI 2.0 is a set of messages and those messages are not tied to any particular cable or connector.
When MIDI first started it could only run over the classic 5 Pin DIN cable and the definition of that connector and how it was built was described in the MIDI 1.0 spec.
However soon the MIDI Manufacturers Association and Association of Music Electronic Industries defined how to run MIDI over many different cables and connectors.
So for many years, MIDI 1.0 has been a transport agnostic protocol..
MIDI 1.0 messages currently run over 5 PIN Din, serial ports, Tip Ring Sleeve 1/8″ cables, Firewire, Ethernet and USB transports.
Can MIDI 2.0 run over those different MIDI 1.0 transports now?
Yes, MIDI 2.0 products can use MIDI 1.0 protocol and even use 5 Pin DIN if they support the Automated Bi-Directional Communication of MIDI-CI and :
- One or more Profiles controllable by MIDI-CI Profile Configuration messages.
- Any Property Data exchange by MIDI-CI Property Exchange messages.
- Any Process Inquiry exchange by MIDI-CI Process Inquiry messages.
However to run the Universal MIDI Packet and take advantage of MIDI 2.0 Voice Channel messages with expanded resolution, there needs to be new specifications written for each transport.
The new Universal Packet Format that will be common to all new transports defined by AMEI and The MIDI Associaton. The new Universal Packet contains both MIDI 1 .0 messages and MIDI 2.0 Voice Channel Messages plus some messages that can be used with both.
The most popular MIDI transport today is USB. The vast majority of MIDI products are connected to computers or hosts via USB.
The USB specification for MIDI 2.0 is the first transport specification completed, but we are working on a UMP Network Transport for Ethernet and Wireless Connectivity
Can MIDI 2.0 provide more reliable timing?
Yes. Products that support the new USB MIDI Version 2 UMP format can provide higher speed for better timing characteristics. More data can be sent between devices to greatly lessen the chances of data bottlenecks that might cause delays.
UMP format also provides optional “Jitter Reduction Timestamps”. These can be implemented for both MIDI 1.0 and MIDI 2.0 in UMP format.
With JR Timestamps, we can mark multiple Notes to play with identical timing. In fact, all MIDI messages can be tagged with precise timing information. This also applies to MIDI Clock messages which can gain more accurate timing.
Goals of JR Timestamps:
- Capture a performance with accurate timing
- Transmit MIDI message with accurate timing over a system that is subject to jitter
- Does not depend on system-wide synchronization, master clock, or explicit clock synchronization between Sender and Receiver.
Note: There are two different sources of error for timing: Jitter (precision) and Latency (sync). The Jitter Reduction Timestamp mechanism only addresses the errors introduced by jitter. The problem of synchronization or time alignment across multiple devices in a system requires a measurement of latency. This is a complex problem and is not addressed by the JR Timestamping mechanism.
Also we have added Delta Time Stamps to the MIDI Clip File Specification.
Can MIDI 2.0 provide more resolution?
Yes, MIDI 1.0 Voice Channel messages are usually 7 bit (14 bit is possible by not so widely implemented because there are only 128 CC messages).
With MIDI 2.0 Voice Channel Messages velocity is 16 bit.
The 128 Control Change messages, 16,384 Registered Controllers, 16,384 Assignable Controllers, Poly and Channel Pressure, and Pitch Bend are all 32 bit resolution.
Can MIDI 2.0 make it easier to have microtonal control and different non-western scales?
Yes, MIDI 2.0 Voice Channel Messages allow Per Note precise control of the pitch of every note to better support non-western scales, arbitrary pitches, note retuning, dynamic pitch fluctuations or inflections, or to escape equal temperament when using the western 12 tone scale.