CAN bus or ethernet is most suitable for a new midi standard. USB is not symmetrical so let hope that it is not part of 2.0.

31250 bps would be grossly inadequate for 32-bit controllers on 16x16 channels. It was already inadequate back in 1990s.

I'd just require all MIDI 2.0 hardware to implement some form of full-duplex Ethernet over twisted pair (100/1000/2.5G/5G) in the DIN connector, with Audio Video Bridging physical layer and AVTP / RTP-MIDI (AppleMIDI) transport layer:

• 1000BASE-T and 2.5GBASE-T/5GBASE-T work over standard 4-pair UTP cables and could employ 8-pin (circular 45-degree) DIN 45326 connectors - so these 8-pin sockets would also accept 5-pin plugs, and the legacy current-loop transceiver could either be physically switched or auto-configured;
  
• 100BASE-T1, 1000BASE-T1 and MG-BASE-T1 (2.5/5/10G) are automotive versions that work over single unshielded twisted pair and could employ the same 5-pin DIN sockets, where the two unused pins would be assignment for the Ethernet link;
  
• 100BASE-TX100 works over 2 pairs, which could also fit the current 5-pin DIN connector using some additional switching logic.
  

CAN bus or ethernet is most suitable for a new midi standard. USB is not symmetrical so let hope that it is not part of 2.0.

It isn't. That is down to the USB standards committee.

31250 bps would be grossly inadequate for 32-bit controllers on 16x16 channels. It was already inadequate back in 1990s.

Back in '83 when MIDI first came out, 31,250bps was a good high speed. I know, I'd been working in data communications for more than ten years at the time.
Try using multiple ports then.
People have been making music quite (very?) successfully using just MIDI 1.0 and 31kbps for more than 3 decades.

Whether the USB standards people decide to implement MIDI 2.0 over USB 3.0 or the upcoming 4.0 is entirely up to them.
Likewise if the IEEE decide to implement the MIDI protocols over Ethernet is up to their standards body.
Likewise the obsolescent Firewire.
What manufacturers implement in their equipment is a matter solely down to the market requirements as they see them, nothing to do with the MMA.

As I posted earlier, I see no proposal for increasing the speed of the basic MIDI over DIN plugs.
It would require a lot of work and massive cost, if at all possible, to upgrade millions of older pieces of equipment to 62,500.

What manufacturers implement in their equipment is a matter solely down to the market requirements as they see them, nothing to do with the MMA.

MMA exists to design and promote common standards for the manufacturers to implement. And without a commonly accepted high-speed link to handle the advanced capabilities, MIDI 2.0 protocol will not have such a broad adoption as MIDI 1.0.

Ethernet with RTP-MIDI (AppleMIDI) UDP/IP transport would be a perfect choice for a common physical interface, scalable from device-to-device link to a large network - especially with AVB extensions (IEEE 802.1BA Audio Video Bridging) for low-latency tight-sync media streaming and related higher-level AVTP transport protocols IEEE 1722/1733, which do support MIDI payload (and MMA is currently working to update AVB MIDI specs to support MIDI 2.0).

It would require a lot of work and massive cost, if at all possible, to upgrade millions of older pieces of equipment to 62,500.

Nobody proposed anything like that, the point was to use a different Ethernet connector for AVB streams.

Dmitry said,

MMA exists to design and promote common standards for the manufacturers to implement. And without a commonly accepted high-speed link to handle the advanced capabilities, MIDI 2.0 protocol will not have such a broad adoption as MIDI 1.0.

Can you honestly see manuafacturers implementing Ethernet in their devices? Yamaha tried a while back, as I recall, without much success.
Yes, maybe MIDI 2.0 would invoke some new interest.
But, to be honest, I see little of general interest in MIDI 2.0. N.B. "general interest!"
Increased bandwidth is for many becoming a necessity these days, I accept.
Personally I find I can do all I need with MIDI 1.0 careful sequencing and multiple ports.

Maybe a few, high end, expensive devices, perhaps.

But it's just my 2 cents.

Both Ethernet (AVB) and USB transports provide the bandwidth necessary to handle MIDI 2.0’s denser messages.
Both are on the roadmap for future MIDI expansion with USB being the priority. Also JIitter Time Stamps will help with timing.

When 5G wireless networks are available, people will be surprised by the speed. Even MIDI 2.0 is tiny compared to streaming video data.

The reason some people complain about USB speed is because some applications throttle what they send out to MIDI 1.0 speeds because currently the computer does not know if the external MIDI Out connection is going to a device connected via USB or 5 Pin DIn.
That issue could be addressed in designing a new USB MIDI 2.0 spec. Remember the current USB MIDI 1.0 spec is 20 years old

As for 5 PIN DIn, Electron had products several years ago that had 10 times the speed of MIDI 1.0 on the same 5 Pin DIN connector, but with a slight modification of the part for the UART. MIDI-CI provides a method for negotiation so it would be possible for two devices to negotiate to a higher bandwidth on 5 Pin DIN. MIDI - CI makes a lot of things possible and we just need to prioritize the work that will get done next.

The forum on MIDI.org is absolutely the right place for people who care about these issues about MIDI to provide their input.

Although we can’t actually reveal details of future MMA plans, the people who help prioritize the work in the MMA do read the forums.

CAN bus or ethernet is most suitable for a new midi standard. USB is not symmetrical so let hope that it is not part of 2.0.

USB-C receptacles has two pairs of D+ / D- signals which will correctly map to the D+ / D- pins of the Type-C plug when plugged in either way, so this makes the plug both symmetrical and reversible...
Using the USB 2.0 standard or above and USB-C connectors, there is no problem with USB symmetry.

USB-C:

Can you honestly see manuafacturers implementing Ethernet in their devices?

Yes, I can. Ethernet over twisted pair is commonplace technology by now, with countless off-the-shelf AVB/TSN compliant 100/1000/2.5G/5G parts. All the required standards are already there, and established audio/MIDI companies like MOTU and Presonus already embraced AVB audio networking in their products.

All it takes for MI vendors to start going is a free open-source reference implementation of the high-level AVTP (IEEE 1722) and AVDECC (IEEE 1722.1) protocols, such as http://avnu.github.io/OpenAvnu / https://github.com/AVnu/libavtp , https://github.com/L-Acoustics/avdecc etc. MMA just needs to work with the IEEE and the AVNU to specify conformance profiles for transmission of MIDI over AVB networks.

Yamaha tried a while back, as I recall, without much success.

That would be Yamaha mLAN network protocol, implemented on top of the IEEE 1394 FireWire physical interface. Proprietary licensed software on top of patent-encumbered, royalty-based hardware protocol.

On the contrary, AVB/TSN suite (bandwidth reservation and traffic shaping extensions to IEEE 802.1Q, network-wide clock sync in IEEE 1588/802.1AS etc.) is based on open international standards supported by both silicon makers and IT/pro-audio developers, with MILAN interoperability testing and certification by the Avnu Alliance.

I see little of general interest in MIDI 2.0. N.B. "general interest!" Maybe a few, high end, expensive devices, perhaps.

Standards need to come first so devices can follow later.

MIDI 2.0 is not such a radical departure for digital synth engines - however all these per-note controllers do require significant changes to the physical controls. If manufacturers will be able to improve keyboard controllers and offer these new means of musical expression in a simple and player-friendly way, general interest will follow.

Can you honestly see manuafacturers implementing Ethernet in their devices?

Anyway MIDI 2.0 is not such a radical departure for digital synth engines - but all these per-note controllers do require significant changes to the physical controls. If keyboards could be improved to offer these new means of musical expression in simple and player-friendly way, then general interest will follow.

Don't you think Roli will be one of the leading companies to use MIDI 2.0?
They sure have some great devices capable of humanizing the playing aspect of MIDI instruments already!

Like the next-gen MPE devices, implemented with MIDI 2.0

Craig Anderton Article

some applications throttle what they send out to MIDI 1.0 speeds because currently the computer does not know if the external MIDI Out connection is going to a device connected via USB or 5 Pin DIn.
That issue could be addressed in designing a new USB MIDI 2.0 spec..

Great - USB 2.0 Hi-Speed mode (480 Mbit/s), not to mention USB 3 and USB4/ThunderBolt3 (5/10/20/40 Gbit/s), would sure be nice, as many users only have a few devices each directly connected to the PC. This will not improve device-to-device connection though.

Electron had products several years ago that had 10 times the speed of MIDI 1.0 on the same 5 Pin DIN connector, but with a slight modification of the part for the UART. MIDI-CI provides a method for negotiation so it would be possible for two devices to negotiate to a higher bandwidth on 5 Pin DIN

Digital current loop interface can't be improved to offer megabit speeds over several meters, this requires modern serial interfaces using differential signalling over twisted pair (Ethernet, RS-485, M-LVDS, etc).

Some very interesting contributions to this thread.

It promises to be a very exciting couple of years in terms of new devices supporting MIDI 2.0 and higher speed interfaces, doesn't it.

I look forward to future announcements with great interest.

Don't you think Roli will be one of the leading companies to use MIDI 2.0?

Sure, ROLI seem to take very active part in MIDI 2.0 development and testing.
However 49-key silicone pad with toy keys is just not my kind of keyboard controller.

I really look forward to Yamaha, Roland and others to start integrating touch/pressure sensitive pads into their traditional synth-action and weighted-action keys.

Like the next-gen MPE devices, implemented with MIDI 2.0

MPE is a kind of hack intended for older MIDI 1.0 devices, which uses additional MIDI channels to send per-note controllers.

On the other hand, MIDI 2.0 includes per-note controllers at the core level, and only needs MPE for backward compatibility.

Don't you think Roli will be one of the leading companies to use MIDI 2.0?

Sure, ROLI seem to take very active part in MIDI 2.0 development and testing.
However 49-key silicone pad with toy keys is just not my kind of keyboard controller.

I really look forward to Yamaha, Roland and others to start integrating touch/pressure sensitive pads into their traditional synth-action and weighted-action keys.

Like the next-gen MPE devices, implemented with MIDI 2.0

MPE is a kind of hack intended for older MIDI 1.0 devices, which uses additional MIDI channels to send per-note controllers.

On the other hand, MIDI 2.0 includes per-note controllers at the core level, and only needs MPE for backward compatibility.

MPE seems to be a bodge to get around the limits of only one PolyAftertouch channel and destroys multitimbrality by having it as part of midi2 does that mean no more multitimbral synths?

Shouldn't it be left as a hack/bodge and not implemented as part of the standard. seems like some people want to have their cake & eat it.

MIDI 2.0 should be an all new standard and have a clean break from the old MIDI 1.0 this is a standard there is no point in backward comparability in the standard old kit can still use MIDI 1.0 DAWs will need to work with both. Hardware will be 1.0, 2.0 or Both there is no point in trying to shoehorn 1.0 comparability into 2.0 it will just make 2.0 worse.

---------------------------------------------------------

As for connections it all needs to be done through Ethernet it's much more reliable than USB when you start scaling your setup USB hubs just don't compete with Ethernet switches when it comes to stability.

MPE seems to be a bodge to get around the limits of only one PolyAftertouch channel and destroys multitimbrality

It's not as dramatic, the MPE protocol can use whatever number of channels is configured by end user with the Registered Control Number (RPN) message 0006 'MPE Control Messsage' (MCM).

by having it as part of midi2 does that mean no more multitimbral synths?
Shouldn't it be left as a hack/bodge and not implemented as part of the standard.

Absolutely not.

The new MIDI 2.0 protocol includes note-on events with 16-bit velocity and 16-bit per-note articulation (aftertouch, plucking, glide etc.) or other attributes (tuning etc.), as well as per-note pitchbend and per-note continuous controllers with even finer 32-bit resolution, and a total of 256 MIDI channels (in 16 groups of 16 channels) - that's a lot of multitimbrality to me.

On the other hand, MIDI 2.0 is also designed to fully support the existing ecosystem. It uses "Universal MIDI Packets" which can encapsulate new MIDI 2.0 events or the old 1.0 events within each group of 16 channels. This makes it easy for 2.0 devices to maintain compatibility with 1.0 devices on the legacy 5-pin DIN port, which is limited to 16 channels. And since the new protocol is a superset of the old, translation from MIDI 2.0 Protocol events to 1.0/MPE events (and vice versa) should be pretty straightforward, even though some loss of resolution will occur.

More than that, MIDI 2.0 devices are explicitly allowed to use the old 1.0 events for their internal synth engine states, but implement new physical transports, MIDI-CI and the MIDI 2.0 packet-based protocol - that provides manufacturers with an easy adoption path, by enhancing existing MIDI 1.0 hardware solutions with support for additional MIDI channels and better timing precision.

In simpler words, MIDI 1.0 sources can use up to 256 channels for MIDI Polyphonic Expression (MPE) if they choose to implement MIDI 2.0 Universal Packet over USB or Ethernet/AVB connections, and MIDI 2.0 sources will use native per-note events for expression control.

https://en.wikipedia.org/wiki/MIDI#MIDI_2.0
https://www.midi.org/articles-old/details-about-midi-2-0-midi-ci-profiles-and-property-exchange

seems like some people want to have their cake & eat it.
MIDI 2.0 should be an all new standard and have a clean break from the old MIDI 1.0
there is no point in trying to shoehorn 1.0 comparability into 2.0 it will just make 2.0 worse.

Tell that to hundred millions of professional users who still use MIDI 1.0. There were attempts to specify non-compatible replacement protocols like Zeta ZIPI and CNMAT Open Sound Control, and they never took off with the musical instrument industy or softsynth developers, simply because of the enormous installed base of MIDI 1.0 devices and software.
Full backward compatibility has been a clearly stated goal for the whole 15 years of 'High-Definition Protocol' development.

As for connections it all needs to be done through Ethernet it's much more reliable than USB when you start scaling your setup

Fully agree here. USB is fine for point-to-point connections like controller-to-computer and instrument-to-computer, but not so much for instrument-to-instrument, controller-to-instrument, or multiple controller-instrument-computer connections in a production network.

The backbone of the transmission interface for the new MIDI 2.0 Protocol shall be

1) Physical layer - Ethernet over twisted pair with Audio Video Bridging (AVB) / Time-Sensitive Networking (TSN), a low-latency tight-sync switching extension of the Ethernet protocol, based on international standard IEEE 802.1Q.

2) Transport layer - IEEE-1722 Layer 2 AV Transport Protocol (AVTP) and IEEE 1733 Layer 3 Transport Protocol extensions for AVB/TSN, based on RFC 3550 Real-time Transport Protocol (RTP). MIDI support is already there as RFC6295 RTP-MIDI transport (implemented as AppleMIDI in OS X), and the MMA is currently working to update the AVTP MIDI specifications.

3) Configuration - IEEE 1722.1 AVDECC Protocol (Discovery, Enumeration, Connection management and Control)

The AVB suite of standards is marketed as MILAN by the Avnu Alliance, and well known players like MOTU and Presonus already offer products for AVB/TSN audio networks - they will no doubt follow with MIDI 2.0 interfaces as soon as the AVTP-MIDI and RTP-MIDI specifications are updated.

Both Ethernet (AVB) and USB transports provide the bandwidth necessary to handle MIDI 2.0’s denser messages.
Both are on the roadmap for future MIDI expansion with USB being the priority. Also JIitter Time Stamps will help with timing.

When 5G wireless networks are available, people will be surprised by the speed. Even MIDI 2.0 is tiny compared to streaming video data.

The reason some people complain about USB speed is because some applications throttle what they send out to MIDI 1.0 speeds because currently the computer does not know if the external MIDI Out connection is going to a device connected via USB or 5 Pin DIn.
That issue could be addressed in designing a new USB MIDI 2.0 spec. Remember the current USB MIDI 1.0 spec is 20 years old

As for 5 PIN DIn, Electron had products several years ago that had 10 times the speed of MIDI 1.0 on the same 5 Pin DIN connector, but with a slight modification of the part for the UART. MIDI-CI provides a method for negotiation so it would be possible for two devices to negotiate to a higher bandwidth on 5 Pin DIN. MIDI - CI makes a lot of things possible and we just need to prioritize the work that will get done next.

The forum on MIDI.org is absolutely the right place for people who care about these issues about MIDI to provide their input.

Although we can’t actually reveal details of future MMA plans, the people who help prioritize the work in the MMA do read the forums.

Hi, so latency will be improved? I was just trying improve my setup sync and it seems this where I will be have to concede to imperfection in the current standard... which is about 5ms up to 7ms or 8ms because of jitter.

my MIDI usb devices are about 1-3ms.

I suppose if Jitter is reduced enough, then compensation protocol can be effectively implemented DAW side to correct the late recording.. such as with ASIO latency and plugin latency compensation?

Can sample accurate latency compensation be possible with MIDI 2.0?

JR Timestamp messages are intended as a prefix to Channel Voice messages (i.e. notes/controllers/pitch-bend/pressure), so that several events in a series are scheduled to sound at a specified time.
They have a resolution of 32 μs (microseconds, i.e. 1 MHz / 32 = 31,25 kHz clock, similar on MIDI 1.0 bitrate) - see the ADC19 MIDI 2.0 presentation starting from 24:50.

This is vastly better than the MIDI 1.0 beat clock of 24 pulses per quarter note (PPQ), and better than Standard MIDI Files (SMF) which typically use up to 960 PPQ resolution (though the SMF format itself is precise down to either 16384 PPQ or 256 ticks per SMPTE frame, which resolves to either 31.5 μs (32768 Khz) at 120 beats per minute (BPM) or 130 μs = 0.13 ms (7680 kHz) at 30 fps).

It's still not "sample-accurate" though - this IMHO would either require a clock that is an exact multiple of 48 kHz (20.8 μs), or a much higher clock of 6 MHz (a least common multiple of 48000 and 31250).

The clock field uses 16 bits while another 4 bits are reserved in the JR Timestamp message, so hopefully higher clocks of 62.5/125/250 Khz - or alternate base clocks like 48/96/192 kHz - could be supported in a future revision.


As for latency, this depends on the transmission medium. The JR Timestamp message only includes the source clock in order to re-arrange events at the sink - but if messages do not arrive within specified time interval (defined by receive buffer size), timestamps are useless.
USB should have the best latency when used for direct to PC connection. For networked setup (AVBTP and RTP-MIDI), you would need to use a high-speed connection like 2.5/5/10/25/40G Ethernet and employ switching equipment that supports AVB/TSN protocols in order to minimize congestion delays.