Notifications
Clear all
Developers & MIDI 2.0 Specifications
2
Posts
2
Users
0
Reactions
3
Views
Topic starter
There is some concern currently with windows updates as it prepares to rollout midi 2.0 and windows asio. I've been seeing reports of peoples midi devices no longer working with windows - it seems like the issues may be related to rewriting windows audio processes - and I am curious if there is something in the midi 2.0 process that not only supports midi 1 class compliant devices but also supports the host of applications that work through hybrid midi 1 functions that were working in windows prior the rollout of the new midi 2.0 and asio processes. Is midi 2.0 replacing midi 1.0? or is midi 1 still going to be supported as a legacy mode so that proprietary drivers still work? I am wondering if a fix can be included in midi 2.0 to provide a legacy mode to recognize if a midi 2.0 device doesn't respond to midi 2.0 but can respond to midi 1 and operate in midi 1 mode. This is directly related to window 11 implementation of midi 2.0 and windows asio but can also apply to other implementation of midi 2.0 where there is old hardware that has custom functions or only relies on some aspects. Is there a reason why midi 1 usb devices will no longer function due to midi 2.0 rollout and what is the fix for this?
Also does patching the UDP midi stack in windows relate to a security flaw with its implementation up to this point? Was it patched due to midi networking being bidirectional now?
This topic was modified 1 week ago 2 times by William Ashley
Posted : 22/02/2025 6:28 pm
> I've been seeing reports of peoples midi devices no longer working with windows - it seems like the issues may be related to rewriting windows audio processes
I would recommend going to the Microsoft MIDI Github and discord to ask some of these questions. However, let's see if we can clear some things up for you.
The new Microsoft MIDI Drivers are under active developement and some intial versions hae been released with the last 2 Canary releases. Being Canary release users are likely to experince problems and should be used to feedback those discoveries to MS for fixing. Current stable version of Windows use the old preexisting drivers.
> and I am curious if there is something in the midi 2.0 process that not only supports midi 1 class compliant devices but also supports the host of applications that work through hybrid midi 1 functions that were working in windows prior the rollout of the new midi 2.0 and asio processes.
Backwards and forwards compatible is important. In windows case MIDI 2.0 devices can work with MIDI 1.0 applications. MIDI 1.0 Devices can work with MIDI 2.0 Applications.
MIDI 2.0 Devices also have MIDI 1.0 descriptors*. This means that a MIDI 2.0 hooked up to a computer that only supports MIDI 1.0 will have access to MIDI 1.0 functiontionality.
> Is midi 2.0 replacing midi 1.0?
MIDI 1.0 Devices will always continue to work as they have 🙂
> or is midi 1 still going to be supported as a legacy mode so that proprietary drivers still work?
Please have a look at the specs to see how MIDI 1.0 is acheived on USB and within UMP.
Proprietry Drivers are another issue. Most Proprietry Drivers are needed for features such as Multi-client support etc. This is now built into the new MIDI stack and should not be needed. However, if you have a specifc driver/concern I'd follow up on the discord channel.
> Also does patching the UDP midi stack in windows relate to a security flaw with its implementation up to this point? Was it patched due to midi networking being bidirectional now?
I am not sure what you are referring to? The new Windows stack can handle a variety of different transports. The UDP MIDI transport in windows is based on the recent released UDP MIDI 2.0 Network spec. It is an early dev only release for testing and is not yet complete.
* technically can be done without, but is not something seen in the wild.
Posted : 03/03/2025 11:29 pm
