Hi, Jan.
Thanks so much for getting back with me.
I have a number of devices that are all supposed to abide by the USB-MIDI standard. Two of them respond as expected using the winmm.dll USB-MIDI API (midiOutGetNumDevs() / midiOutGetDevCapsA / etc). I can find and control these devices programmatically (with the MIDI functions) without a problem.
Some MIDI devices aren’t detected through those functions – the MIDI functions appear to filter out devices that don’t have a MIDI-streaming interface.
Even if they don’t stream MIDI, these devices will still respond to standard MIDI program and control change information through a USB connection – but only if I can get a handle to them. I can talk to them through a hardware USB-MIDI interface (using the round 5-pin DIN connector cables), but those kinds of interfaces are giving way to USB-MIDI (much faster, more versatile interface). The MIDI-specific API is becoming more and more obsolete – this is not been a priority for Microsoft, it hasn’t been updated in over a decade.
Since the MIDI-specific API doesn’t work, I have to take another approach.
I’ve successfully found the devices by feeding a suitable class ID to SetupDiGetClassDevs; I used SetupDiEnumDeviceInterfaces and SetupDiGetDeviceInterfaceDetail to get the device instance ID; I fed the device instance ID to CreateFile to get a Windows handle, then used that Windows handle with WinUSB_Initialize to get a WinUSB handle. And this always fails with “access denied”, even when I know I’m feeding the intended device instance ID into those SetupDi functions.
So I’m guessing that I should be talking to specific interface ID’s in the device, not the device ID itself. With a bit of trial and error, I can find the interface that will execute standard MIDI commands – for some devices, this has been through an interface labeled “AUDIO”. My question had to do with a possible conceptual misunderstanding on my part -- that maybe communication links should be with interfaces rather than devices. (?)