Kappa971 wrote on 2026-01-30, 14:07:

https://forums.steinberg.net/t/news-from-micr … is-week/1022281

Could this be relevant for FSMP or old games?

Yes, because the biggest part of the new MIDI stack in Windows is the backwards compatibility work done to enable the old MIDI hardware and software to work with the latest- and future - Windows OS. Also, many will be using ARM laptops in the near future, for music and retro-gaming, so this is a big win for everyone.

RetroGamer4Ever wrote on Yesterday, 05:42:

Kappa971 wrote on 2026-01-30, 14:07:

https://forums.steinberg.net/t/news-from-micr … is-week/1022281

Could this be relevant for FSMP or old games?

Yes, because the biggest part of the new MIDI stack in Windows is the backwards compatibility work done to enable the old MIDI hardware and software to work with the latest- and future - Windows OS. Also, many will be using ARM laptops in the near future, for music and retro-gaming, so this is a big win for everyone.

I do not think so. The biggest part is not about 'to enable the old MIDI hardware and software to work with the latest- and future - Windows OS'.
The biggest part is about to enable new Midi 2.0 devices to work with the latest- and future - Windows OS.
The compatibility with old hardware (and software) will not be better. In the best case it will be the same. But In the worst case...
Let's see if it's really a big win for everyone. I have my doubts since any changes that affected the Midi stack of Windows in the last 30 years only worsened compatibility with old hardware/software.

Falcosoft wrote on Yesterday, 06:52:

I do not think so. The biggest part is not about 'to enable the old MIDI hardware and software to work with the latest- and fut […]
Show full quote

RetroGamer4Ever wrote on Yesterday, 05:42:

Kappa971 wrote on 2026-01-30, 14:07:

https://forums.steinberg.net/t/news-from-micr … is-week/1022281

Could this be relevant for FSMP or old games?

Yes, because the biggest part of the new MIDI stack in Windows is the backwards compatibility work done to enable the old MIDI hardware and software to work with the latest- and future - Windows OS. Also, many will be using ARM laptops in the near future, for music and retro-gaming, so this is a big win for everyone.

I do not think so. The biggest part is not about 'to enable the old MIDI hardware and software to work with the latest- and future - Windows OS'.
The biggest part is about to enable new Midi 2.0 devices to work with the latest- and future - Windows OS.
The compatibility with old hardware (and software) will not be better. In the best case it will be the same. But In the worst case...
Let's see if it's really a big win for everyone. I have my doubts since any changes that affected the Midi stack of Windows in the last 30 years only worsened compatibility with old hardware/software.

Falcosoft wrote on Yesterday, 06:52:

I do not think so. The biggest part is not about 'to enable the old MIDI hardware and software to work with the latest- and fut […]
Show full quote

RetroGamer4Ever wrote on Yesterday, 05:42:

Kappa971 wrote on 2026-01-30, 14:07:

https://forums.steinberg.net/t/news-from-micr … is-week/1022281

Could this be relevant for FSMP or old games?

Yes, because the biggest part of the new MIDI stack in Windows is the backwards compatibility work done to enable the old MIDI hardware and software to work with the latest- and future - Windows OS. Also, many will be using ARM laptops in the near future, for music and retro-gaming, so this is a big win for everyone.

I do not think so. The biggest part is not about 'to enable the old MIDI hardware and software to work with the latest- and future - Windows OS'.
The biggest part is about to enable new Midi 2.0 devices to work with the latest- and future - Windows OS.
The compatibility with old hardware (and software) will not be better. In the best case it will be the same. But In the worst case...
Let's see if it's really a big win for everyone. I have my doubts since any changes that affected the Midi stack of Windows in the last 30 years only worsened compatibility with old hardware/software.

Backwards and forwards compatibility and significant improvements for using the massive amount of older MIDI 1.0 hardware and software tech already in play took up most of the development time and resources, so it's the biggest part of what's been done. That comes straight from the guy who led the development efforts. 2.0 products are a small amount of what's out there, being used by industry pros and others, so it's all about bringing the past forward, with a path to the future.

RetroGamer4Ever wrote on Yesterday, 07:07:

Falcosoft wrote on Yesterday, 06:52:

I do not think so. The biggest part is not about 'to enable the old MIDI hardware and software to work with the latest- and fut […]
Show full quote

RetroGamer4Ever wrote on Yesterday, 05:42:

Yes, because the biggest part of the new MIDI stack in Windows is the backwards compatibility work done to enable the old MIDI hardware and software to work with the latest- and future - Windows OS. Also, many will be using ARM laptops in the near future, for music and retro-gaming, so this is a big win for everyone.

I do not think so. The biggest part is not about 'to enable the old MIDI hardware and software to work with the latest- and future - Windows OS'.
The biggest part is about to enable new Midi 2.0 devices to work with the latest- and future - Windows OS.
The compatibility with old hardware (and software) will not be better. In the best case it will be the same. But In the worst case...
Let's see if it's really a big win for everyone. I have my doubts since any changes that affected the Midi stack of Windows in the last 30 years only worsened compatibility with old hardware/software.

Backwards and forwards compatibility and significant improvements for using the massive amount of older MIDI 1.0 hardware and software tech already in play took up most of the development time and resources, so it's the biggest part of what's been done. That comes straight from the guy who led the development efforts. 2.0 products are a small amount of what's out there, being used by industry pros and others, so it's all about bringing the past forward, with a path to the future.

Let's see what will be your opinion when you have already checked and tried it...
BTW, even the post at Steinberg that Kappa971 linked mostly talks about WinRT and Midi 2.0 devices support in Cubase besides the multi-client capability.

Some quotes from the new MIDI stack's documentation:

The new driver supports both MIDI 2.0 devices as well as MIDI 1.0 devices. By default, we do not currently move existing MIDI 1.0 devices to the new driver because we need to be sure of compatibility first.

The service, transports, and plumbing are all there for MIDI 2.0, however apps will need to use the Windows MIDI Services App SDK to interface with it. The existing WinMM and WinRT MIDI 1.0 APIs cannot support the newer constructs, message scheduling, creating virtual device apps, etc. All of those features are in the new SDK.

That is, they try to preserve compatibility mostly by not touching and not interfering with Midi 1 hardware/drivers/APIs/apps.
This does not sound like that the focus and most of the developments are related to old hardware/software and backward compatibility.

Regarding ARM laptops and the new MIDI 2.0 services:
According to the description the new services will not affect how kernel drivers work on ARM. Old hardware that needs kernel drivers but only has native x86/x64 drivers will not work even with the new MIDI stack on ARM Windows.
So backward compatibility roughly starts with the USB era and does not include the most relevant hardware for old games like the classic Roland and Yamaha gears.
E.g. If you want to use Roland/Yamaha serial port drivers your best option remains an x86 32-bit Windows.

RetroGamer4Ever wrote on Yesterday, 07:07:

...
Backwards and forwards compatibility and significant improvements for using the massive amount of older MIDI 1.0 hardware and software tech already in play took up most of the development time and resources,

BTW, I have a very bad feeling because of this:
https://devblogs.microsoft.com/windows-music- … i-driver-limit/

It says:

Midisrv now handles all enumeration of MIDI-capable devices, and uses a completely different way to find the connected Kernel Streaming drivers in the system, including our own MIDI 1.0 and MIDI 2.0 class drivers, as well as third-party KS MIDI drivers. Anything which is not a KS driver, must be implemented in another way.

As well as:

We also recognize that customers may install third-party drivers just due to preference or habit, and that a subset of those drivers continue to make updates to the Drivers32 entries. Therefore, the Windows MIDI Services App SDK includes a tool midifixreg.exe which will reset the registry to the Windows MIDI Services default setup with just wdmaud.drv and wdmaud2.drv. Your devices will continue to work regardless of the KS driver they use because once wdmaud2.drv is loaded, all enumeration happens in the service.

The problems is that all of the user mode soft synth MIDI drivers that retro enthusiasts use are not KS (kernel streaming) drivers but use the old installable multimedia driver architecture (they are simple user mode dlls, there is no accompanying drv/sys device driver component) and rely on the Drivers32 entries in the registry.
This includes the Munt driver, Nuked OPL3 emulation drivers, Coolsoft Virtual Midi Synth as well as VST MIDI driver.
I hope I'm not right but according to the description these drivers will all belong to the 'must be implemented in another way' camp since they have no Kernel Streaming driver component and thus the new Midi service will not enumerate them..

From the same dev blog entry: Anything which is not a KS driver, must be implemented in another way. For example, our built-in loopback endpoints are handled completely in service code, as is the Network MIDI 2.0 preview implementation, and the Virtual Device implementation. We`ve built an infrastructure using classic COM to make it easier to write new transports without having to create kernel drivers, or mess with these registry entries.

Surely, a little elbow grease and tinkering will get everything working, if it doesn't work. They are only starting the initial roll-out of the general release and many things will be changed by the end of the year, as more testing of hardware and drivers are being done. I'll see what is what when the update hits one of my Win 11 laptops.

RetroGamer4Ever wrote on Yesterday, 15:29:

From the same dev blog entry: Anything which is not a KS driver, must be implemented in another way. For example, our built-in loopback endpoints are handled completely in service code, as is the Network MIDI 2.0 preview implementation, and the Virtual Device implementation. We`ve built an infrastructure using classic COM to make it easier to write new transports without having to create kernel drivers, or mess with these registry entries.

Surely, a little elbow grease and tinkering will get everything working, if it doesn't work. They are only starting the initial roll-out of the general release and many things will be changed by the end of the year, as more testing of hardware and drivers are being done. I'll see what is what when the update hits one of my Win 11 laptops.

Yep, we have to wait a little and then we will see. I still hope that at least there will be a compatibility setting to make the old driver architecture work as it worked so far. To tell you the truth C/C++ COM programming is not much fun and most likely the required modifications will make the code Win 11+ specific. So either Win 11 specific new forks or in place dynamic code alternations would be required. Neither is ideal considering that e.g. VST MIDI driver's current version can be the same from WinNT4 to Win 11.