Windows 11 finally hits right note: MIDI 2.0 support arrives

Microsoft has finally ushered in the era of MIDI 2.0 for Windows 11, more than a year after first teasing the functionality for Windows Insiders. In addition to a raft of enhancements, Microsoft has addressed several key user pain points in this release: allowing multiple applications to use the same MIDI device and port …

[Wally Dug]

Hit The Right Notes

FTFY:

"It looks like you're trying to make some sweet, sweet music. Do you want some hi-hat with that?"

[Neil Barnes]

Re: Hit The Right Notes

It looks like you're trying to make some sweet, sweet music. If you'll describe the elevator to me, I can make sure its tailored correctly.

[David 132]

Re: Hit The Right Notes

Are you just trying to drum up support?

Anyway, a Microsoft new feature that doesn't involve AI - let's hope this is a cymbal of things to come.

(Why yes, that's my coat there, thank you, I'll be leaving...)

[Pete 2]

Re: Hit The Right Notes

I do hope nobody snares at your comment

[Anonymous Coward]

Re: Hit The Right Notes

Expected to hear more about this direct from Microsoft themselves; not like them to miss an opportunity to blow their own General MIDI instrument number 57.

[Dizzy Dwarf]

eBay -->

--> Atari ST

[Anonymous Coward]

> the end of badly written OEM drivers

We can replace them with a badly written Microsoft driver.

[simonlb]

Badly written and now due to go to acceptance testing by the general public.

FTFY.

[Dwarf]

Progress

Of all the things they could have done - Why now

Why after all these years, surely most aren't playing with MIDI now, or if they are, then they are using something a bit more reliable than Windows, with its forced updates. Imagine that in the middle of a concert.

Why is there not something more important they could have fixed with the same engineering resources, such as notepad.

Perhaps they are training their new vibe coding AI, v14.3 to see if it can do basic stuff.

Even a 1MHz BBC micro from the 1980's could do MIDI reliably, with only 16K of ROM and 32K of RAM. It wasn't a difficult thing to do even back then - 40 odd years ago.

[Anonymous Coward]

Re: Progress

> surely most aren't playing with MIDI now

You might want to take a look at synth specs before saying things like that: MIDI is alive and well (which may be why they spent the time on the MIDI 2.0 spec in the first place)

> then they are using something a bit more reliable than Windows, with its forced updates. Imagine that in the middle of a concert.

Lots of MIDI used in the studio. And to stop unexpected Windows updates, don't let it connect to the Internet during the concert!

But, yes, there are lots and lots of other MIDI sources and destinations than Windows. See "MIDI is alive and well".

> Even a 1MHz BBC micro from the 1980's could do MIDI reliably, with only 16K of ROM and 32K of RAM. It wasn't a difficult thing to do even back then - 40 odd years ago.

Correct. MIDI 1.0 was defined in 1983 and lots of machines could do varying amounts of stuff with it.

But as TFA points out, MIDI 2.0 came out in 2020 and there are not so many working BBC Micros left, so people are slumming it on Windows.

> Why is there not something more important they could have fixed with the same engineering resources, such as notepad.

Oh no, this doesn't help me so it is a waste of time. Would you like some bread with your bean soup?

[Dwarf]

Re: Progress

My point is that MIDI is a stupidly simple protocol that has been around for donkeys years (and no el reg doesn't have a reg-approved unit for that).

But, if you look at all other similar low baud rate serial protocols that have been around for decades and take very little processing to make them work. Most have similar functions within microcontrollers and microprocessors. So, needing to get Windows 11 to finally provide MIDI2 support seem to me to be stupid, in the same way that if the article was saying that Windows 11 now supports other such protocols - I2C, SPI, UART (RS232, RS485, RS422, etc), 1 wire, CAN, then people would be laughing.

Its not difficult, so why has it taken multiple decades to get Windows support for this ?

I accept that the BBC micro may not be the platform of choice now, it was an indicator that any old CPU can handle the workload.

[jonathan keith]

Re: Progress

I think you missed an important part of the article. Windows now supports MIDI 2.0. Windows has supported the original MIDI system for - as you say - decades.

And MIDI is one of those rare things: an industry standard that has actually stood the test of time remarkably well*, to the point where it's taken this long to get to the point where it really benefits from being revised. And the opportunities that MIDI 2.0 present are genuinely exciting for musicians.

* unless you're talking about the Suzuki Q-chord, which has the most demented MIDI implementation I've ever come across, and which could only have been a product of the copious ingestion of recreational drugs. (The MIDI implementation, not the Q-chord. Although...) Those crazy music-industry engineers, eh?

[Cloudseer]

Re: Progress

It’s the protocol that allows professional music equipment to exchange note, instrument and song information so without it you’d be reduced to sampling essentially

[J.G.Harston]

Re: Progress

The Beeb is 2MHz, and if you only had 16K of ROM you wouldn't be able to do anything with it as you wouldn't be able to get to a command prompt to enter or load any code. At a minimum you'd need 32K of ROM, the OS plus a language, usually BASIC.

I'm another of those that built a BBC MIDI interface, and wrote drivers for it. Lovely being able to do *MIDI ON then run a music program and everything comes piping out of my Casio. :)

[Will Godfrey]

Good in parts.

MIDI was overdue for an overhaul, so in many ways this is a considerable improvement. However it also makes it possible for manufacturers to create walled gardens. As well as a variety of transports (just about all currently available ones!) a manufacturer can build a wealth of complex unique controls which they are under no obligation to publish.

The saving grace is that to be compliant the kit must be able to fall back to MIDI 1, which has all the primary controls specified.

[Pete 2]

Give it time

> a refreshing change for Microsoft, as it does not mention Copilot or AI at all.

Yet!

I am old enough to remember when albums by Queen contained the words "no synthesisers" on the cover. The reason: the tech was crude and didn't provide the nuance and finesse of a person tickling the ivories.

But as synthesisers developed, that changed. A parallel, perhaps?

[Anonymous Coward]

Re: Give it time

> A parallel, perhaps?

MIDI is still definitely a serial protocol, even over the new transports that 2.0 (finally) standardises :-)

[cosmodrome]

There's nothing well-written about MS' MIDI driver

The whole thing has been broken by design since the advent of USB-Midi. Not only will Windows reinstall any MIDI device that connects via USB as a new device wheneveit connects to a different port, it also has a completely idiotic limit of 16 devices. No operating systems except Windows does that shit. It gets even worse: some very smart person decided to give every virtuutal audio device including audio channels on HDMI-enabled monitors their own MIDI-device. Yes, they will create extra devices if reconnected to different ports on multiscreen setups. So, swap left and right screen and half of your MIDI resources are gone without having connected a single MIDI device or fired up a DAW.

[Gary Daniels]

Re: There's nothing well-written about MS' MIDI driver

The source for the new USB MIDI 2.0 driver, which is MIDI 1.0 compatible, is available here: https://github.com/microsoft/MIDI/tree/main/src/api/Drivers/USBMIDI2/Driver

Feel free to make suggestions if you see any way to improve it. It's a completely different driver than the old MIDI 1 driver, it's only loosely KS based, it now transfers the data over cross process memory mapped buffers rather than through separate ioctl's for each message. Further, it leverages the open-source project, AM_MIDI2, for all of the conversions and MIDI message parsing, ensuring that it's reliable and follows standards.

The whole MIDI 2.0 stack for Windows is now open source, feel free to make contributions or file bugs. You just have to turn on developer mode and take ownership of the inbox files to swap them out with your own compiled versions.

The new Windows MIDI 2.0 stack does not have a 16 device limit. That is a limitation of the legacy winmm driver architecture from the 9x days. To work around this, Windows MIDI Services adds a single "legacy" device named "wdmaud2.drv" for winmm clients, and that one device publishes all of the ports across all of the devices available from the new MIDI service. This way if you still have any of the really old devices from the '80's, you can still add up to 14 of them. But, everything else that goes through the new service, USB, network, loopback, or KS drivers, no longer consume entries in that 16 device list at all and are not constrained by it. Yes, the 16 device limit was a problem, and it has been addressed.

The issues with plugging a MIDI peripheral into a different plug happens when a peripheral doesn't report a serial number, which is necessary for disambiguating peripherals whenever you have more than one of the same device. Without a serial number, the operating system has to use the plug the peripheral is plugged into to disambiguate. It's an issue that affects all operating systems to varying degrees. Manufacturers are being actively encouraged by The MIDI Association to add a serial number to the peripheral firmware. https://midi.org/building-a-usb-midi-2-0-device-part-1

We're certainly open to any suggestions to make it better.

Regarding the issue with every audio device being identified as midi devices, that has also been addressed. I whole heartedly agree, it was a problem. This is an artifact from back when midi was part of the sound card. The midi device tag was included in the inf for the sample audio driver due to the historical association with audio, and every. single. audio. driver. since. has gotten that tag identifying them as a "wdmaud" midi device, whether they support midi or not. This caused them to be automatically added into the 16 device list whenever they were installed, and the issues you describe with a monitor breaking the midi device installs.

Going forward, the drivers32\midi* entries are no longer managed by the audio endpoint builder service, whenever you use a 3rd party tool to install legacy winmm drivers, those will remain unmodified by Windows. There are 2 required entries in that list, "midi"="wdmaud.drv" for the midi synthesizer, and "midi1"="wdmaud2.drv" for Windows MIDI Services. The rest are left to the community to manage. Though it is worth mentioning that any drivers installed through this path will only be accessible through the legacy winmm api, they won't support multi-client and can't be accessed through the new MIDI 2 API. Though, I wouldn't be surprised if at some point someone makes a wrapper transport for midisrv to make these legacy devices accessible through the service. Could be a fun side project for someone interested in contributing to MIDI on Windows.

Hope that helps.

-Gary