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. 

MIDI 2.0 Overview

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 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. 

First, we'll talk about MIDI-CI which uses MIDI 1.0 Universal Sysex so it can be run on any current MIDI 1.0 transport (5 PIN DIN, USB MIDI 1.0, RTP MIDI, Bluetooth MIDI, Web MIDI, etc.) or MIDI 2.0 transports. 

MIDI-CI Includes Queries for 3 major areas of expanded MIDI functionality described in detail below:

1. Profile Configuration
2. Property Exchange
3. Process Inquiry

After that we will talk about UMP Discovery, MIDI 1.0, and MIDI 2.0 protocols. 

MIDI-CI Profile Configuration

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.

There are some common types of MIDI devices that all tend to do very similar things. We can define Profiles to define how MIDI controls the common features. MIDI-CI Profile Configuration allows devices to discover and turn on Profiles for better interoperability and ease of use while lowering the need for manual configuration of devices by users.

To explain, let's consider MIDI controlled 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. A Piano Profile might define that Note Number 60 is Middle C, define a specific velocity response curve, define the use of a variable Sustain Pedal (not just On/Off) message, define a controller message for the angle of the lid opening, define a message to select the type of stretch tuning, and more. Any device that reports support for the Piano Profile would have to conform to that design.

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. If 2 devices agree to use a common Profile, MIDI-CI Profile Configuration can auto-configure the mappings. Profiles can be written for device types or for unique applications that are used across multiple device types. Profiles might be written for instruments such as pianos, electric pianos, drawbar organs, drum sets, analog synthesizers. Feature Profiles could define common messages to control orchestral articulation, direct pitch control models, or per-note expression. Profile can also serve non-musical applications such as controlling PTZ cameras, lighting controllers or industrial machines.

The following video has a demonstration of how Profile Configuration works.

The MIDI Association has completed the first Profile, 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 MIDI Association is currently working on the following MIDI-CI Profiles that are targeted to finished in 2023.

Piano Profile

Drawbar Organ Profile

MPE Profile

Camera Control Profile

Orchestral Articulation Note On/Off Profile

GM 16 Channel Profile

GM Single Channel Profile 

We are planning a series of articles exploring the details of each of these Profiles. 

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.

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

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.

Products can become part of the MIDI 2.0 world without implementing either UMP or the MIDI 2.0 Protocol. 

MIDI 2.0 is about bi-directional communication and so if a product implements MIDI-CI and any Profile or Property Exchange, it qualifies to use the MIDI Association's MIDI 2.0 logo. 

Can MIDI 2.0 run over those different MIDI 1.0 transports now?

No, there needs to be new specifications written for each transport. 

There is a new Universal Packet Format that will be common to all modern transports that will help make this work move quicker. The new Universal Packet contains both MIDI 1 .0 messages and MIDI 2.0 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 was the first transport specification completed. 

We are currently working on a network transport. 

Can MIDI 2.0 provide more resolution?

Yes, MIDI 1.0 messages are usually 7 bit (14 bit is possible by not widely implemented because there are only 128 CC messages). In MIDI 2.0 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 allows 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 ( see videos).

Can MIDI 2.0 provide more reliable timing?

Yes. MIDI 2.0 transport definitions 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.

MIDI 2.0 also provides optional "Jitter Reduction Timestamps".

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.