Details about MIDI 2.0™, MIDI-CI, Profiles and Property Exchange (Updated November 2022)

The core MIDI 2. Specifications are available for download by MIDI Association Individual Members

Corporate Members have access to all specifications including those under development

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.

As a MIDI developer, we want to let you know about some changes and improvements that are coming to the core MIDI 2.0 specifications. 

The MIDI Association will be presenting two important MIDI 2.0 sessions at the Audio Developers Conference on Nov. 15-16, 2022 that will discuss these changes.

Those ADC sessions are important because since adopting the core MIDI 2.0 specifications in January of 2020, we have been working hard to develop the infrastructure necessary and then prototype those MIDI 2.0 specs.

During that process we discussed and agreed on some significant improvements to the core specifications that are in the final process of review and voting by the MIDI Association and AMEI.

Perhaps most obvious example is that one of the three P's of Profiles Configuration, Property Exchange and Protocol Negotiation will change.

We plan to deprecate Profile Negotiation via MIDI-CI in favor of a simpler method accomplished by a new UMP message.

But there are still three P's because we created a new P called Process Inquiry.

As the MIDI Association, we share with AMEI the awesome responsibility of advancing MIDI while maintaining compatibility with MIDI products made all the back in 1983. 

So we are sure that everyone appreciates that we need to take the time to test things completely before releasing MIDI 2.0 products.

Here is an overview of the changes that we will be sharing at ADC.

Updates to Minimum Compatibility Requirements of MIDI 2.0 

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.

Updates to MIDI-CI

This version contains all errata and feature changes or additions since MIDI-CI version 1.1. The most significant changes include:

• Added features for backward and forward compatibility through future update versions. To ensure compatibility with previous and future MIDI-CI versions, every MIDI-CI implementation shall follow the rules defined in Section 5.4.
• Deprecated Protocol Negotiation.

These mechanisms have been replaced by MIDI Endpoint mechanisms defined in the M2-104-UM Universal MIDI Packet (UMP) Format and MIDI 2.0 Protocol, Version 1.1 specification

• Removed Bidirectional Settings and Authority Level sections (were only used by Protocol Negotiation).
• Added Section 9, Process Inquiry. This version of MIDI-CI introduces a new category of MIDI-CI, Process Inquiry, which allows an Initiator to discover the current state of supported MIDI Messages including:
  • System Messages
  • Channel Controller Messages
  • Note Data Messages
• Added Section 7.6, Profile Details Inquiry Message
  The Profile Details Inquiry message is used by an Initiator to discover details of the Profile implementation of a Responder. For example, an Initiator might discover:
  • How many Channels may be used or assigned by the Responder for a multi-channel Profile.
  • The Note Range supported by the Responder for the Profile.
  • Which optional Profile features the Responder is capable of supporting.

The details which may be discovered are defined by the specification for the requested Profile Id.

• Added Profile Added Report and Profile Removed Report List messages.
• Added Section 3.1, 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.
• Expanded addressing capabilities due to the addition of Function Blocks.
• Fixed an error in the SubID#2 for the Invalidate MUID message in MIDI-CI Version 1.1. The specification defined a SubID#2 with value 0x7E, while the table in the final Appendix listed it as 0x72. The value 0x7E is the correct value.

Updates to UMP and MIDI 2.0 Protocol

This version contains all errata and feature changes or additions since UMP and MIDI 2.0 Protocol version 1.0. The most significant changes include:

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

Traduzione Italiana 

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 Includes Queries for 3 major areas of expanded MIDI functionality:

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

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 SELECTION 

       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.  

Message Type Examples:  

1.5.2 Groups  

The Universal MIDI Packet 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 Protocol. Therefore, a single connection can carry both protocols simultaneously. MIDI 1.0 Protocol and MIDI Protocol messages cannot be mixed together within 1 Group. 

1.5.3 Jitter Reduction Timestamps 

The Universal MIDI Packet format adds a Jitter Reduction Timestamp mechanism. A Timestamp can be prepended to any MIDI 1.0 Protocol message or MIDI 2.0 Protocol message for improved timing accuracy.  

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

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

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

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

1.7 What's Next 

The USB-IF working group has passed the new MIDI 2.0 USB specification. 

Roland has released a MIDI 2.0 ready controller.  

There are even some new MIDI 2.0 products from companies who are not part of the MIDI Association. 

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.  

On the Monday after NAMM, some of the dedicated team of volunteer MMA and AMEI members held 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 

1.8 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?

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. 

USB specification for MIDI 2.0 will be the first transport specification completed.

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.

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

Videos of the MIDI 2.0 prototyping session at Winter NAMM 2019 

The really exciting part of MIDI-CI is that Protocol Negotiation 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, chairman of AMEI