I know this plugin isn't maintained, but logging this here in case other folks plan to use this plugin. This came up from someone using this plugin under the new MIDI stack in Windows.
On each and every frame, for each and every incoming midi message, this plugin calls midiInGetNumDevs, and then closes and reopens each and every MIDI port on the system.
This was a really bad idea even under the old WinMM stack. But under the new version that is part of Windows MIDI Services in Windows 11, opening and closing connections is much more expensive. That's because we now have a Windows Service in between, to make every port multi-client, add translation, routing, and much more. So opening a connection involves making RPC calls and creating a memory mapped file. If it's the only connection to the device, it also involves opening up the driver with kernel calls. Then, when closing the connection, this all has to be backed out, file cleaned up, etc.
We never thought that an app would close and reopen connections to devices for every incoming MIDI message in every render frame. So we optimized for message IO, not connection setup.
More information about the new MIDI stack is here: https://aka.ms/mididiscord
Related issue here: microsoft/MIDI#976
On a related note, I saw that this plugin is very loose with how it treats handles and gets back port names. It never checks for validity of handles or pointers, so could result in crashes.
Pete
Microsoft
I know this plugin isn't maintained, but logging this here in case other folks plan to use this plugin. This came up from someone using this plugin under the new MIDI stack in Windows.
On each and every frame, for each and every incoming midi message, this plugin calls midiInGetNumDevs, and then closes and reopens each and every MIDI port on the system.
This was a really bad idea even under the old WinMM stack. But under the new version that is part of Windows MIDI Services in Windows 11, opening and closing connections is much more expensive. That's because we now have a Windows Service in between, to make every port multi-client, add translation, routing, and much more. So opening a connection involves making RPC calls and creating a memory mapped file. If it's the only connection to the device, it also involves opening up the driver with kernel calls. Then, when closing the connection, this all has to be backed out, file cleaned up, etc.
We never thought that an app would close and reopen connections to devices for every incoming MIDI message in every render frame. So we optimized for message IO, not connection setup.
More information about the new MIDI stack is here: https://aka.ms/mididiscord
Related issue here: microsoft/MIDI#976
On a related note, I saw that this plugin is very loose with how it treats handles and gets back port names. It never checks for validity of handles or pointers, so could result in crashes.
Pete
Microsoft