- Notifications
You must be signed in to change notification settings - Fork 50
Description
Describe the bug
Different port names for MIDI 1.0 from Windows MIDI Services vs. WinMM are problematic
To Reproduce
Connect external MIDI device and compare MIDI 1.0 port names of Windows MIDI Service vs WinMM
Expected behavior
Port names for MIDI 1.0 from Windows MIDI Services vs. WinMM should be the same
Screenshots
Screen shots of MIDI configurations Screenshot_comparison_WinMM_WinMIDIServices.zip
Installer Name or Version
Customer Preview 1 - Feb 5, 2025 Windows Insider Canary
Desktop (please complete the following information):
Windows 11 Canary, OS Build 27788.100
Device information, if this is with an external MIDI device:
Yamaha keyboard PSR-S910
Yamaha Driver: USB-MIDI Driver V3.1.4 for Win 11/10/8.1/8/7 (64-bit)
https://de.yamaha.com/de/support/updates/umd_win64_kbd.html
Application Information
Notation Composer, Musician, Player from www.notation.com
Additional context
One essential point for MIDI 2.0 is that the exsiting interface for MIDI 1.0 is kept and stays the same. This fundamential principle is key to use existing MIDI 1.0 hardware AND software. I consider it to be problematic that port names for MIDI 1.0 are different with Windows MIDI Services compared to the port names provided by the WinMM interface.
Let me bring up an example:
The Yamaha PSR-S910 keyboard has two ports:
Port 1: input to and output from the software
Port 2: output from the software
WinMM offer the interface calls midiInGetDevCaps, midiOutGetDevCaps to retrieve the port names from keyboard.
WinMM result of midiGetDevCaps / midiOutGetDevCaps gives:
Port 1:
midiInGetDevCaps
MIDIINCAPS midiInCaps.szPname = "Digital Keyboard-1"
midiOutGetDevCaps
MIDIOUTCAPS midiOutCaps.szPname = "Digital Keyboard-1"
Port:2
midiOutGetDevCaps
MIDIOUTCAPS midiOutCaps.szPname = "Digital Keyboard-2"
Windows MIDI Services result of midiGetDevCaps / midiOutGetDevCaps gives:
midiInGetDevCaps
MIDIINCAPS midiInCaps.szPname = "Yamaha USB-MIDI-1 I-1"
midiOutGetDevCaps
MIDIOUTCAPS midiOutCaps.szPname = "Yamaha USB-MIDI-1 O-1"
midiOutGetDevCaps
MIDIOUTCAPS midiOutCaps.szPname = "Yamaha USB-MIDI-2 O-2"
Due to the downward compatibility of Windows MIDI Servives with the WinMM interface introducing a new naming scheme is problematic because:
(1) ports have different names now
(2) exiting apps need to be changed to achieve the same logic that input and output ports can be associated to each other
Since the early days of the WinMM interface the names of the ports are used to associate input- and output ports to each other. Further the port names are used through the software to determine a certain behavior. Such behavior of MIDI ports is stored in device configuration files by a software addressed by the name of ports. We have customers who verbosely use such configuration files where they connect up to 50 different USB MIDI devices at the same time. A typical kind of an "unusual" MIDI device is the Ampero Control foot switch (https://www.hotone.com/products/controlers/Ampero%20Control) ) Folks use such MIDI devices to switch instruments in live performances. Another example is that folks created MIDI tracks for MIDI devices (addressed by name) to launch smoke on stage by certain MIDI events. Keeping the name of such devices between WinMM and Windows MIDI Services is essential.
From a user point of view it is not acceptable that all the configuration setups have to be adopted due to an update of Windows 11.
I fully appreciate all the work and ideas which have been incorporated for MIDI 2.0 and in particular to be downwards compatible to MIDI 1.0. But on the other side this new design needs to meet the real world of existing solutions which are available for ~30 years now.
Thanks for understanding such situations.
Reinhold Hoffmann
CEO of Notation Software www.notation.com
Sub-issues
Metadata
Metadata
Assignees
Labels
Type
Projects
Status