ah, I see the/a difference in distinction among some folk, I think.
USB as a standard describes a physical connection along with some rules about how to transfer information over that standardized connection.
midi started as that (5 pin and the mini jack) but, especially once USB took over the world, is much more just the description of data to move over a (somewhat) arbitrary physical (or not––ie bluetooth) connection.
Sure, everything is data. I’m just pointing out that MIDI data is not about and will not be about audio data.
We have plenty of those, including this thing called “USB Class Compliant”.
The problem you probably want to see solved is how multiple audio devices can be merged into a single aggregate device more easily? This is inherently harder than it might appear as a result of the latency inherent in digital systems and the need to keep everything synced to a master clock.
But regardless, that’s outside the scope of what the MIDI Consortium works on.
Simple answer: costs. Especially something like Overbridge becomes a nightmare to develop and maintain when you need to support different (ever-changing) operating systems. Ask Elektron … 
Indeed although I guess usb class compliance handles that, but that’s why I was thinking if you had something like MIDI as the universal audio data format it wud be up to the OS to support MIDI not the other way round!
Article about midi 2.0 and what it is, I saw they were having a meeting at NAMM now it’s finally confirmed
What I want to know is, if this becomes a new standard, would it be possible for the newer Elektrons with MIDI over USB to adopt it? And if so…
If using a MIDI controller which also adopted the protocol, could this solve the infamous value jumps when changing patterns? Considering the bi directional communication aspect
About effin time!
Looking forward to all future made synths implementing 16 bit velocity data and 32bit CC data 
But puhlease… use ethernet connector instead of USB! Ethernet is way superior, and already has an entire industry supporting how its distributed and networked reliably (using existing routers / switches, PoE etc)
Using USB only makes sense for “portable instruments” and enabling MIDI 2.0 functionality for existing hardware
MIDI 1.0 allowed 16 bit CC data, but most equipment manufacturers never took advantage of this feature.
I’d be wary of potential latency, unless it were an isolated network. Could be worth a customised set of protocol layers produced, to reduce some of the 7-layer over-heads which wouldn’t necessarily be required for MIDI.
Do you mean 14-bit CC data?
What latency? Dante uses ethernet and has less latency than most soundcards
Id like to see more widespread adoption of Ethernet for midi - RTP MIDI support is pretty sporadic, and there are compatibility issues.
also if we want better jitter/latency over usb (on general purpose computers) perhaps support for midi over isosyncrhonous usb protocol
(*) the protocol used for audio, and hence we dont have issues with audio over usb!
midi 1.0 14bit cc has a slight issue when being used for continuous control - but im hoping midi-ci may be able to help out… as you’ll know if a controller is spitting out 14 bit or not.
Yes and no. Bidirectional communication is already possible. On the OT there exists a CC parameters request which spills out all CC parameters and their values so a controller can sync itself to it (when the controller can utilize this CC feedback).
BUT: even with Midi 2.0 its not a given that such features are implemented by the device and the controller. There is no “requirement” that a device needs to do this.
IMHO the real benefits are the higher bandwidth, much more channels and value ranges and that there are standards for the bi-directional communication part. So hopefully not each manufacturer “creates” again its own variant. Implementation should also become easier due to the shared standards.
While the future gets painted in happy rainbow colors I’m quite skeptical if retrofitting MIDI 2.0 into older devices will bring much benefits or is even possible. Its all depends on how “open” the hardware of the device was initially designed and if there is enough space and cpu power left to handle to additional stuff. From my experience most devices are designed to fit exactly what they are doing now to keep the costs down.
I read that Dante uses its own protocol, in pretty-much the same way as I describe above.
Edit: According to the Wiki link below, it comes in at OSI Layer 3, therefore it seems to dispense with some of the (higher I think) layers.
Also, from the link below:
“Dante networks must be on the same LAN.”. So, perhaps not necessarily fully isolated, but it doesn’t and can’t support WAN - pretty much as I thought. WAN would be where potential latency would creep in. You’d probably want to isolate the LAN anyhow, so that stray packets don’t get in the way and add latency.
I write (part of the job) networking software for a living. Mainly WAN though, or dedicated multi-cast networks, carrying multi-media / TV, which is why the idea of Ethernet networking rang alarm bells. I know full-well what happens when things go wrong. 
https://www.audinate.com/resources/faqs
Edit: also, this extract (from the same link), highlights one of my concerns:
"Most off-the-shelf switches are fine for use with Dante, apart from unmanaged switches with Energy Efficient Ethernet (EEE), which interferes with Dante clocking.
[PDF link] lists some of the switches that are not compatible with Dante."
So - you’d potentially need to carefully select your network switch.
Dante Via, which I think is the system which uses a PC’s inbuilt network interface, adds 10ms latency by default (info from same link above). Although, a dedicated PCIe interface, can reduce that latency to below 1ms.
I also consider these the greater news… but was curious about that bi-directional protocol - and of course, it had to be adopted by the manufacturers… still, could be super interesting, we’ll see what the future holds!
Ok, so ethernet carries its own set of problems. But are you saying you’d actually prefer USB?
What appeals me with ethernet is that cable runs arent as limited like with USB, and ethernet connectors have locking clasps and so on… Not sure how their ground hygiene is but IME ground hygiene cannot get much more messed up than with using USB. And groundloops, who loves em? nobody.
Its not too uncommon to read about people online complaining that hey connected something over USB, only to find they now polluted their entire signal path with ground noise.
Yes I did Peter, 16 bit CC which allows 14 bit data (I have edited my original post).
My point being that I doubt we will see many devices supporting 32 bit resolution.
Not at all. I’m not a big fan of USB as-is, especially for streaming applications. USB typically uses host CPU clock cycles, which means that a system would need enough bandwidth for that. …but a deeper dive might show it to be more appropriate than Ethernet. Not saying for sure at this point, which is why I’m saying that I’d be “wary”. I’d need more info.
I think the issue is essentially - hardware standardisation. Ethernet connectors themselves might be fine for the job, but it might need custom data-link firmware, or possibly even special PHYs for the job, which I’m guessing is essentially how Dante does it with their dedicated PCIe card.
That would certainly be possible, but would mean that MIDI 2 could be more than just a software protocol spec. You’d certainly get standardisation on cables, but the device interface might not be exactly the same as a standard Ethernet interface.
Your response just killed any hope for ethernet conns for me. I’m afraid manufs will stick with USB in that case. A shame
O’well, at least we will finally get proper resolution for velocity and CC, along with MPE-style expression capability.