Main Content

Details about MIDI 2.0™, MIDI-CI, Profiles and Property Exchange

On Sunday, January 19, 2020 at the Annual Meeting of the MIDI Manufacturers Association, the complete suite of MIDI 2.0 specifications were adopted unanimously by the MMA members in attendance .

These five core documents serve as the basis for the future expansion of MIDI.

The MIDI specifications adopted at Winter NAMM included:

MIDI Capability Inquiry (update)
Universal MIDI Packet & MIDI 2.0 protocol
Common Rules for MIDI-CI Profiles
Common Rules for MIDI-CI Property Exchange
MIDI 2.0 Specifications​ Overview

The specifications are now being edited to their final format for official signing by AMEI (the Association of Music Electronics Industry, the Japanese MIDI standards organization) and then will be available for public download.

Introduction to MIDI 2.0™
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. Here’s why MIDI 2.0 is the biggest advance in music technology in decades.

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. For example, with the new MIDI-CI (Capability Inquiry) 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.

Higher Resolution, More Controllers and Better Timing

To deliver an unprecedented level of nuanced musical and artistic expressiveness, MIDI 2.0 re-imagines the role of performance controllers, the aspect of MIDI that translates human performance gestures to data computers can understand. Controllers are now easier to use, and there are more of them: over 32,000 controllers, including controls for individual notes. Enhanced, 32-bit resolution gives controls a smooth, continuous, “analog” feel. New Note-On options were added for articulation control and precise note pitch. In addition, dynamic response (velocity) has been upgraded. What’s more, major timing improvements in MIDI 2.0 can apply to MIDI 1.0 devices—in fact, some MIDI 1.0 gear can even “retrofit” certain MIDI 2.0 features.

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.

Property Exchange

While Profiles set up an entire device, Property Exchange messages provide specific, detailed information sharing. These messages can discover, retrieve, and set many properties like preset names, individual parameter settings, and unique functionalities—basically, everything a MIDI 2.0 device needs to know about another MIDI 2.0 device. For example, your recording software could display everything you need to know about a synthesizer onscreen, effectively bringing hardware synths up to the same level of recallability as their software counterparts.

Built for the Future.

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 (like USB or Ethernet). 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.

1.1 MIDI Capability Inquiry (MIDI-CI)
The additional capabilities that MIDI 2.0 brings to devices are enabled by MIDI-CI. The basic idea is that if devices have a bidirectional connection, they can exchange their capabilities with each other. Devices can share their configuration and what MIDI functions are supported.

Devices use a bidirectional link to configure MIDI features when both devices agree to support that feature. MIDI-CI discovers and configures device features using 3 categories of inquiry: Profile Configuration, Property Exchange, and Protocol Negotiation.

If a device does not support any new features, it uses the MIDI 1.0 as usual. Devices connected to that device will continue to use MIDI 1.0 in communication with that device.

Expanding MIDI with new features requires a new protocol with extended MIDI messages. To protect backwards compatibility in an environment with expanded features, devices need to confirm the capabilities of other connected devices. When 2 devices are connected to each other, they use MIDI 1.0 and 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. MIDI-CI provides this mechanism.

MIDI-CI: Expanding MIDI while Protecting Backwards Compatibility:

MIDI Capability Inquiry (MIDI-CI) is a mechanism to allow us to expand MIDI with new features while protecting backward compatibility with MIDI devices that do not understand these newly defined features.

MIDI-CI separates older MIDI products from newer products with new capabilities and provides a mechanism for two MIDI devices to understand what new capabilities are supported.

MIDI-CI assumes and requires bidirectional communication. Once a MIDI-CI connection is established between devices, query and response messages define what capabilities each device has.

MIDI-CI then negotiates or auto-configures to use those features that are common between the devices. MIDI-CI provides test mechanisms when enabling new features. If a test fails, then devices fall back to using MIDI 1.0 for that feature. MIDI-CI improves MIDI capabilities in several key areas.

MIDI-CI allows devices to use an expanded MIDI protocol with high resolution and multiple per note controllers. It allows for incremental adoption of new MIDI features by providing a fallback to MIDI 1.0 devices in all cases.

MIDI-CI Includes Queries for 3 major areas of expanded MIDI functionality:

Profile Configuration
Property Exchange
Protocol Negotiation

1.2 PROFILE CONFIGURATION
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 lighting controllers or industrial machines.

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

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

1.4 PROTOCOL NEGOTIATION
MIDI-CI Protocol Negotiation allows devices to select between using the MIDI 1.0 Protocol or the MIDI 2.0 Protocol. Two devices that have established a 2-way MIDI-CI session can select a Protocol and features of that Protocol. ​

A MIDI Protocol is the language of MIDI, or the set of messages that MIDI uses. Architectural concepts and semantics from MIDI 1.0 are the same in the MIDI 2.0 Protocol. Compatibility for translation to/from MIDI 1.0 Protocol is given high priority in the design of MIDI 2.0 Protocol.​

The MIDI 1.0 Protocol and the MIDI 2.0 Protocol have many messages in common, messages that are identical in both protocols. The MIDI 2.0 Protocol extends some MIDI 1.0 messages with higher resolution and new features. There are newly defined messages. Some can be used in both protocols and some are exclusive to the MIDI 2.0 Protocol.

1.5 MIDI 1.0 Protocol, MIDI 2.0 Protocol and the Universal MIDI Packet
MIDI 2.0 has a new Universal MIDI Packet format for carrying MIDI 1.0 Protocol messages and MIDI 2.0 Protocol messages. A Universal MIDI Packet contains a MIDI message which consists of one to four 32-bit words.

The Universal MIDI Packet format is suited to sending MIDI data over high speed transports such as USB or a network connection or between applications running inside a personal computer OS.

The traditional 5 pin DIN transport from MIDI 1.0 uses a byte stream rather than packets. At the moment, there is no plan to use the Universal MIDI Packet on the 5 pin DIN transport. Unless/Until that plan changes, 5 pin DIN will only support the MIDI 1.0 Protocol.

1.5.1 Message Types
The first 4 bits of every message contain a Message Type. The Message Type is used as a classification of message functions.”

Link to article