A very surprise thing from Microsoft, new MIDI features:

https://blogs.windows.com/windows-i...1-insider-preview-build-27788-canary-channel/

So on a quick read: MIDI 2.0 support (whatever that means, it works fine already), multiclient MIDI ports (yeah!), better timing, loopback MIDI ports, network MIDI, and a new MIDI control panel.

All in all, looks like a great update but I can't tell if apps need to be built using the new SDK, if so, then a lot of these features are moot. They say backwards compatibility, but I'm somewhat skeptical.

Of course, remains to be seen how all of this works, but if they manage to handle multiclient ports, I'm over the moon. I'm sure most of us already install loopMIDI and rtpMIDI to get some of this stuff anyway, but who knows?

 

Thanks @Will Kweks for the good news!

Unfortunately, there are currently hardly any devices that are 2.0 capable, the following text is from Amazona:

As already mentioned above, MIDI 2.0 will be completely backwards compatible with the old MIDI devices. However, MIDI 2.0 can only show its advantages if the transmitter and receiver use the new system, logically! Not only will the DIN sockets remain, but the USB and network solutions will (probably) also continue to exist. So the good news: everything can stay as it was, no beloved synthesizer or valued effects device will soon have to be sold off in the electronic bay or in the reverb.

There were no MIDI 2.0 devices to be seen at the Winter NAMM 2019 - despite bold announcements. It was only at the Winter NAMM 2020 that Roland was able to present the first device that supports MIDI 2.0 with the master keyboard mentioned above. If things continue at the same pace, the MIDI 1.0 device park will be with us for a very long time. Some sequencers (e.g. Cubase and Nuendo) have integrated MIDI 2.0-like features in their products.

There are also suitable master keyboards such as the Seaboard Keyboard. It remains to be seen to what extent these features can be linked to MIDI 2.0. At the Winter NAMM 2020, it was announced that a USB-IF working group is already working on a MIDI 2.0 USB specification.

Source: www.amazona.de/alle-informationen-zum-midi-2-0-standard/

 

this is a huge deal, if it means I can keep my Seaboard plugged in without its driver being hijacked by whatever (DAW) process calls first

 

Christ, I have been reading about Midi 2.0 since before I had the internet easily available in Keyboard magazine and the like (hell, like 1989? or reading tech sheets on proposals and whatnot)..... I guess the spec wasn't formalized until 2020, and I think Android and Apple have had it for almost 4 1/2 years or so... but getting windows in means a lot due to the installed base, and is great for all of us...as devs and manufacturers are certainly more inclined with it's backwards compatibility to pay attention to it with Windows on board for sure...

 

@sisyphus I think MPE disrupted the plan for MIDI 2.0 release, being major enough leap to incorporate into the standard, another thing being (fader) control steps beyond 128 without sacrificing banks or program changes

 

that is a great point tzzsmk, agreed in it's disruption, as worthy inclusion, and important/relevant enough to delay on...

We didn't need confusion with a MIDI 2.1 (featuring MPE!) etc...

 

While I'm cautiously optimistic about the MIDI network support, as a practical concern I kind of think what it could onto the table that CoreMIDI/rtpMIDI/Bonjour/ZeroConf can't at the moment.

The whole 2.0 discovery thing in general would be awesome to have, where devices (or software) could just broadcast their features and have them automatically mapped to whatever. Maybe that's a pipe dream, but I like the idea.

 

I gotta dig into the press release, but what do you suspect that can be done that the others don't or won't easily? (and I'm not asking rhetorically...)... (or am I reading it backwards?)

We've had promises of broadcasted features and mapping and whatnot forever (granted, all third party and not by spec, and by more rote work with different devs and synths etc, ... but if it's spec (or is that not? sorry, I gotta do my homework and you shouldn't have to do it for me), why wouldn't the others have that at the table? (although lol, I imagine apple would see getting "broadcasted" to via midi 2.0 as a security risk one would have to open up in the security system settings etc ffs)

 

Well, MIDI2.0 has provision for device discovery, applicable to any sort of connection (be it physical or via a network), and then the MIDI-CI/Property Exchange. Even if half-baked, I'd rather have one single shared protocol instead of one per manufacturer. I think most of us who've used proprietary things like MCU/Kontrol/Automap agree that those solutions are still annoyingly clumsy.

Weird thing you say Apple who've done broadcast network MIDI for years by now, that's why I keep mentioning CoreMIDI (or the Windows implementation rtpMIDI), which to me is the most workable solution so far. Granted, it's only standard MIDI data, but still.

 

I agree with you having used damn MCU's/NI Kontrols/and the f'n Automap and more.... sigh.. and a standard, rather then trying to get other people to join in (although ironically how midi began), and with everything else I've wasted too much time too much and money on... well...

But Apple HAS had midi 2.0 built in and accessible within CoreMidi since 2021... not just standard midi. And android had it right after to my understanding and memory.

And absolutely, even if the spec isn't perfect, it's better then 20 different idiots running in different directions claiming theirs is better (even if it is as no one is is getting on board with it etc...)

 

The thing that is looking like the best improvement is the support for faster USB which benefits MIDI and audio people alike for latency at 80Gbps.

 

Note: I've not tried to implement it or anything, but reading through the Property Exchange documents shows that it's at least somewhat reasonably specified while the MIDI-CI protocol itself looks fairly complex, but it's built on top of SysEx strings so that's bound to happen.

But basically it's a web protocol-ish bidirectional exchange of JSON data, getters and setters and property lists. Now that looks fairly good way to proceed with things. To me getting a list of CC numbers with names instead of dealing with a third party entity or a plugin format specific way seems way better than anything we have now.

 

I'll skip this update and wait for 3.0.