Details about MIDI 2.0, MIDI-CI, Profiles and Property Exchange (Updated June, 2023)

This article is for companies looking to develop MIDI 2.0 products, both software developers and hardware manufacturers. If you are a MIDI user looking for the benefits of MIDI 2.0, go to this article, which is a more general overview of MIDI 2.0 features. 

THE NEWEST CORE MIDI 2.0 SPECIFICATIONS ARE AVAILABLE FOR DOWNLOAD BY REGISTERING YOUR EMAIL ADDRESS ON THIS WEBSITE

Foundational specifications for MIDI 2.0 were released in February 2020, which allowed MIDI Association members, including Operating System companies to start actually implementing MIDI 2.0. 

Since that time the MIDI Association and its members have been developing tools for and prototyping the first MIDI 2.0  products. 

As a result, we have been improving and enhancing the specifications. 

The MIDI Association and AMEI adopted the following notable specifications on May 29, 2023 and these are now the specifications that should be used as references for developing MIDI products.

If you previously downloaded MIDI 2.0 specifications, please download the latest revisions. 

CURRENT CORE MIDI 2.0 SPECIFICATIONS 

These core specifications define the architectural foundations for MIDI 2.0 and the MIDI 2.0 Specification overview and defines minimum requirements for devices to claim MIDI 2.0 compatibility and to apply to use the MIDI Association's MIDI 2.0 logo.

• M2-100-U MIDI 2.0 Specification Overview, Version 1.1 NEW
• M2-101-UM MIDI Capability Inquiry (MIDI-CI), Version 1.2 NEW
• M2-102-U Common Rules for MIDI-CI Profiles, Version 1.1 NEW
• M2-103-UM Common Rules for Property Exchange, Version 1.1
• M2-104-UM Universal MIDI Packet (UMP) Format and MIDI 2.0 Protocol, Version 1.1 NEW
• M2-116-U MIDI Clip File (SMF2), Version 1.0 NEW

Documents labeled as NEW are notable updates released in June 2023.

There are numerous other MIDI 2.0 specifications which build on these core documents available for download and listed below.

NEW MIDI 2.0 Specification Overview- Version 1.1

The MIDI 2.0 Specification Overview outlines those documents which define the core architecture of MIDI 2.0 It also defines the Minimum Compatibility Requirements for MIDI 2.0

Summary of Minimum Compatibility Requirements for MIDI 2.0

(Updated June 2023)

Any Device which claims MIDI 2.0 compatibility shall implement either A or B, or both A and B:

A. MIDI-CI* to at least its minimum requirements, including discovery mechanisms, plus any one or more of the following features:

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

B. The UMP Data Format** to at least its minimum requirements, including discovery mechanisms, plus any one or more of the following features:

• MIDI 2.0 Channel Voice Messages as defined by the Universal MIDI Packet (UMP) Format and MIDI 2.0 Protocol.
• Jitter Reduction Timestamps as defined by the Universal MIDI Packet (UMP) Format and MIDI 2.0 Protocol.
• System Exclusive 8 as defined by the Universal MIDI Packet (UMP) Format and MIDI 2.0 Protocol.
• Mixed Data Set as defined by the Universal MIDI Packet (UMP) Format and MIDI 2.0 Protocol.

NEW MIDI Capability Inquiry (MIDI-CI)- Version 1.2

MIDI Capability Inquiry (MIDI-CI) is a set of bidirectional mechanisms which allow devices to negotiate with each other for autoconfiguration. MIDI-CI also allows the expansion of MIDI with new features while protecting backward compatibility with MIDI Devices that do not understand these newly defined features.

Latest Notable Changes:

Adds Process Inquiry. Deprecates Protocol Negotiation (replaced by new Protocol Selection mechanisms in (UMP) Format and MIDI 2.0 Protocol) . Adds Function Blocks. Added Profile Details Inquiry. Added features for backward and forward compatibility through future update versions.

NEW Common Rules for MIDI-CI Profiles, Version 1.1

The Common Rules for Profiles complements MIDI-CI by defining a set of design rules for all Profile Specifications.

Latest Notable Changes:

Update to align with updates to MIDI-CI and UMP Format & MIDI 2.0 Protocol specifications. Added Profile Details Inquiry messages. Added Profile Added Report and Profile Removed Report messages. Added Function Block Profiles and made resulting adjustments to Profile Addresses. 

Common Rules for Property Exchange, Version 1.1

The Common Rules for MIDI-CI Property Exchange, complements MIDI-CI by defining a set of design rules for all Property Exchange Resources and Properties.

Unchanged since 2020. 

NEW Universal MIDI Packet (UMP) Format and MIDI 2.0 Protocol

The Universal MIDI Packet provides a standardized modern packet format for all MIDI messages, both MIDI 1.0 Protocol and MIDI 2.0 Protocol. This specification also defines messages in the MIDI 2.0 Protocol.

Latest Notable Changes:

• Added the notion of Groupless messages. Some UMP Message Types are not sent to a specific Group. These messages are intended to be processed by the MIDI Endpoint.
• Utility messages (Message Type 0x0) are now Groupless. Group field is changed to Reserved.
• Added Section 6, Function Blocks.
  • A Device may have one or more Function Blocks. A Function Block is a single functional component or application that operates on a set of one or more Groups. Function Blocks are used to separate a Device's functional components into manageable units. System Messages are also now sent to a Function Block instead of to each Group, reducing the need for multiple messages.
• Added MIDI Endpoint Messages (Message Type 0xF)
  • These Groupless messages are used to discover details about a MIDI Endpoint and its Function Blocks. Discovery of Max System Exclusive 8 Messages has been moved to these messages.
• Added Flex Data Messages (Message Type 0xD)
  • Flex Data Messages are used to send messages to a Channel, Group or a Function Block. New Flex Data Messages include Lyric and Text messages as well messages useful to the MIDI Clip Specification.
• Added Utility Messages for use in the MIDI Clip File specification.
• Deprecated MIDI-CI Protocol Negotiation
  • These mechanisms have been replaced by MIDI Endpoint mechanisms and the Protocol Request and Protocol Notification Utility Messages.
• Added a Per-Note Pitch Sensitivity Registered Controller Message
• Clarifying specific CC/RPN Message translation between MIDI 1.0 and MIDI 2.0 Protocol
• Added MIDI 2.0 Addressing Appendix to help clarify if messages are meant for a Channel, Group, Function Block or MIDI Endpoint.

Other Adopted MIDI 2.0 Specifications available on the site for download. 

• 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
• Default_Control_Change_Mapping_Profile
• MIDI_2-0_Bit_Scaling_and_Resolution
• Property_Exchange_Controller_Resources

You must be logged in as a TMA member to download the spec. If you are not a member yet (or not logged in) , clicking on the link will take you to the signup page to either create an account or log in. 

CORPORATE MEMBERS HAVE ACCESS TO ALL SPECIFICATIONS INCLUDING THESE AND OTHERS UNDER DEVELOPMENT: 

• UMP Network Transport for Ethernet and Wireless Connectivity
• UMP Serial Transport
• Piano Profile
• Orchestral Articulation Profile for MIDI 2.0 Note On and Note Off
• MPE Profile
• OS API Implementation Guide
• Camera Control Profile
• DAW and Mixer Control Profile
• MIDI 2.0 Container File Format (SMF2)

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

DATA FORMATS: MIDI 1.0 BYTE STREAM DATA FORMAT AND UNIVERSAL MIDI PACKET FORMAT

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

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.

The first nibble in each packet declares the Message Type. Each Message Type has a defined size and standard format. 

Example: MIDI 2.0 Protocol messages in the UMP Format have higher resolution data and can have added properties in new data fields. Here is a comparison of a MIDI 1.0 Note On message in the byte stream format and a MIDI 2.0 Note On message in UMP Format. 

Addressing: UNIVERSAL MIDI PACKET FORMAT EXPANDS BEYOND MIDI 1.0 FORMAT

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, with the Channel number declared in the 2nd nibble of the Status Byte. 

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

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. 

All MIDI 1.0 System Messages and Channel Voice messages have equivalent messages within a single Group of the UMP Format. Each Group is roughly comparable to a MIDI 1.0 connection when performing Translations between MIDI 1.0 Byte Stream Format and UMP Format. So 16 Groups can be translated to/from 16 MIDI 1.0 byte stream connections. 

TRANSPORTS AND FILES: WITH UNIVERSAL MIDI PACKET FORMAT 

The Universal MIDI Packet is intended to be the native format for all future MIDI systems supporting both MIDI 1.0 and MIDI 2.0. New or updated, bidirectional transports and new file formats are needed to use the Universal MIDI Packet Format.

UNIVERSAL SERIAL BUS

USB has become a widely used transport for MIDI 1.0. The USB-IF working group has published the USB Class Definition for MIDI Devices v2.0 specification. This uses the Universal MIDI Packet as its native data format for connections between devices and computers.. This includes a mechanism for fall back to USB MIDI 1.0. Both specifications are available for download from https://www.usb.org/documents?search=midi

NETWORK

The MIDI Association's Transport Working Group is currently developing a specification to use the Universal MIDI Packet on network connections for multiple devices, with or without a computer.

OPERATING SYSTEM API FOR MIDI 2.0 - APPLE, GOOGLE, MICROSOFT, LINUX

The MIDI Association's OS API Working Group is developing implementation guidelines for developers. Key members include representatives for operating systems from Apple, Google, and Microsoft, as well as the ALSA team for Linux. These members have been cooperating to unify architectural concepts as much as possible in their diverse environment so that developers can find core, common concepts across platforms.

https://www.midi.org/midi-articles/midi-is-about-collaboration-not-competition

STANDARD MIDI FILE Version 2

MIDI 2.0 requires new Standard MIDI File formats to support the UNiversal MIDI Packet. There are 2 file formats expected, one published and another under development.

1. This MIDI Clip File specification defines a Standard MIDI File format which supports all MIDI 1.0 data and all MIDI 2.0 data. The MIDI Clip File serves a role which is similar to the version 1 Standard MIDI File Type 0, with all data in a single sequence of Universal MIDI Packet messages.
2. The MIDI Container File specification is currently under development, with expected release in 2024. This MIDI Container File supports the Universal MIDI Packet data format by containing one or more MIDI Clip Files, arranged in one or more tracks. This container format also expands the applications and markets for Standard MIDI Files by allowing the inclusion of other media files including musical notation, audio, video, and application-specific files.

The Standard MIDI File version 1 specifications for Type 0 and Type 1 defined certain non-MIDI data as Meta Events. In fact, MIDI SMF1 was developed before the concept of metadata was well defined in the multimedia industry and was ahead of its time in codifying authors, publishers, tempo, key signatures and other aspects of musical performance that have now become standardized for the Internet.

MIDI 2.0 provides more space to define new messages, so these Meta Events have been replaced by new MIDI messages that can be sent over MIDI transports. These new messages can be found in the UMP Format and MIDI 2.0 Protocol specification, V1.1. 

JITTER REDUCTION TIMESTAMPS FOR TRANSPORTS 

The Universal MIDI Packet format adds an optional Jitter Reduction Timestamp mechanism using 2 messages:

1. The JR Clock message defines the current time of the Sender. The Sender sends independent JR Clock messages, not related to any other message.
2. The JR Timestamp message can be prepended to any MIDI 1.0 Protocol message or MIDI 2.0 Protocol message for improved timing accuracy over any transport.

DELTA CLOCKSTAMPS FOR SMF2 

Delta Clockstamp mechanism is used in a MIDI Clip File to declare precise timing of events in a sequence file. A Delta Clockstamp Ticks Per Quarter Note sets the timing resolution and accuracy. Then Delta Clockstamp messages declare the number of ticks since the last event. The timing of every non-Clockstamp message is set by the most recent preceding Delta Clockstamp. 

DISCOVERY

UMP Endpoint

The UMP Format defines mechanisms for Devices to discover fundamental properties of other Devices to connect, communicate and address messages. Discoverable properties on a UMP Endpoint include:

1. Device Identifiers: Name, Manufacturer, Model, Version, and Product Instance Id (e.g. Serial Number).

2. Data Formats Supported: Version of UMP Format*, 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 

Function Blocks

A Device uses Function Block messages to report topology information including the Group address(es) in use. It also reports metadata including the name of the function, MIDI-CI support, hints for user interfaces which expose senders and receivers for user connection choices, and more.

MIDI-CI - MIDI Capability Inquiry

MIDI-CI is used to discover information about the MIDI features found on each Function Block, Group, and/or MIDI Channel of a Device. MIDI-CI includes queries for three major areas of MIDI functionality:

1. Profile Configuration: Profiles define specific implementations of a set of MIDI messages chosen to suit a particular instrument, Device type, or to accomplish a particular task. Two Devices that conform to the same Profile will generally have greater interoperability between them than Devices using MIDI without Profiles. Profiles increase interoperability and ease of use while reducing the amount of manual configuration of Devices by users.
2. Property Exchange is used to Inquire, Get, and Set many properties including but not limited to Device configuration settings, a list of controllers and resolution, a list of patches with names and other metadata, manufacturer, model number, and version. All data is expressed using JSON key:value properties inside System Exclusive messages.
3. Process Inquiry allows discovery of the current state of properties which are controllable by MIDI Messages in a device including:

• Values controlled by System Messages

• Values controlled by Channel Controller Messages

• Values controlled by Note Data Messages 

MIDI MESSAGES

The Universal MIDI Packet Data Format can carry MIDI 1.0 Protocol messages or MIDI 2.0 Protocol messages.  

MIDI 1.0 Protocol Inside the Universal MIDI Packet

All existing MIDI 1.0 messages are carried in the Universal MIDI 1.0. As an example, this diagram from the protocol specification shows how MIDI 1.0 Channel Voice Messages are carried in 32-bit packets:  

System messages, other than System Exclusive, are encoded similarly to Channel Voice Messages. System Exclusive messages vary in size, can be very large, and can span multiple Universal MIDI Packets.  

MIDI 2.0 Protocol Messages

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.

The MIDI 2.0 Program Change message always selects a Program. A Bank Valid bit (B) determines whether a Bank Select is also performed by the message.

If Bank Valid = 0, then the receiver performs the Program Change without selecting a new Bank; The receiver keeps its currently selected Bank. Bank MSB and Bank LSB data fields are filled with zeroes.

If Bank Valid = 1, then the receiver performs both Bank and Program Change.

Other option flags that are not defined yet and are Reserved. 

New Data Messages for MIDI 1.0 Protocol and MIDI 2.0 Protocol 

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. Both messages can be used when using the Universal MIDI Packet format for MIDI 1.0 Protocol or MIDI 2.0 Protocol.  

1.6 The Future of MIDI 1.0

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. 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 or Property Exchange.  

What's Next 

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.

Various Working Groups of the MIDI Association hold weekly or bi-weekly meetings to continue the development of MIDI 2.0.

A great example of the collaboration inside the MIDI Association is the meeting that happened in Tokyo, April 2023. All of the major OS companies gathered with Japanese MIDI manufacturers to talk about details of handling MIDI 2.0 in operating systems. In the true spirit of MIDI, companies set aside their differences and competitive natures to cooperate for the greater benefit of musicians around the world. 

On the Monday after each NAMM Show, some of the dedicated team of volunteer MMA and AMEI members attend an all day planning meeting to map out the plans for the next year.

Front Row : 

• Florian Bomers – Bome Software, MMA Technical Standards Board
• Kaz Hikawa- Crimson Technology, AMEI MIDI Standards Committee 
• Athan Billias- Yamaha, MMA Exec Board
• Koichi Mizumoto, Roland – AMEI , Future of MIDI Expansion (MIDI 2.0) working group chair
• Mike Kent, MK2 Image, MMA Technical Standards Board, MIDI CI working group chair

Second Row:

• Rick Cohen- Qubiq, MMA Technical Standards Board Chair, Protocol Working Group chair
• Franz Detro, Native Instruments
• Evan Balster , imitone
• Daisuke Miura- Yamaha, AMEI Technical Standards Board Chair
• Shunsuke Tanaka- Crimson Technology
• Takahisa Ishiguro - Stone System. 
• Lawrence Levine – Horn, MMA Exec Board, MIDI 2.0 Marketing working group co-chair

Holding MIDI 2.0 banner:

• Andrew Mee – Yamaha consultant for Property Exchange
• Rob Rampley- Media Overkill 

Why Join the MMA (MIDI Manufacturers Association)

If you are a developer of MIDI software or hardware, there are a lot of reasons to join the MIDI Manufacturers Association now.  This article includes some information about MIDI 2.0, but it is definitely not enough to start developing a MIDI 2.0 product.  The reason we do not release specification details before they are finally approved is that if information is released too early and then changes are made, it can lead to interoperability problems.  

If you join the MMA now, you not only get access to the current version of the full MIDI 2.0 specification, but will also have a voice in future MIDI specifications including Profiles and Property Exchange messages.   

To implement MIDI-CI and MIDI 2.0, you need a manufacturers SysEx ID.  A SysEx ID by itself is $260 a year, but it is included with your MMA membership.  You will also have access to the MMA Github which has code for MIDI 2.0 to MIDI 1.0 translation (and vis versa),  MIDI 2.0 Scope, a tool for sending and testing MIDI 2.0 messages developed by Art and Logic and Property Exchange Work Bench, an application developed by Yamaha for prototyping and testing Property Exchange. 

We are also working on a MIDI 2.0 logo and logo licensing program. 

So we encourage you to join the MIDI Manufacturers Association now and get access to all the documents you will need to get a head start on MIDI 2.0. 

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 ( see videos).

The really exciting part of Automated Bi-Directional Communication is that it paves the way for a new industry standard MIDI protocol which could enable new features like higher resolution, more channels and improved performance and expressiveness (while still maintaining backwards compatibility with current MIDI 1.0 devices). A new MIDI protocol would offer a bridge between music technology and new emerging technologies in other industries and allow creators, performers, and consumers to enjoy new and exciting musical experiences in the future.

by Yutaka Hasegawa, former chairman of AMEI