The API should expose MIDI devices, even though they are in the "Audio" class.

[7ombie]

The policy of not allowing any access to devices in the Audio Class prevents access to MIDI devices that have no actual audio capabilities whatsoever. Launchpads are a perfect example. I cannot access my Launchpad X with WebUSB.

I understand there's a WebMIDI API, but that has never been a serious option. It only runs on the main thread, which makes it useless for production audio applications. That issue (support workers) has been open for almost ten years, without any substantial progress.

This is obviously an unusual situation, but fundamentally, this spec should not blacklist device classes on the basis that there are higher-level APIs, when those APIs do not work with that class of devices, or do not provide the functionality the devices require to function properly.

There's no particular reason to blacklist USB-MIDI functions.

Bringing MIDI controllers to the Web would be useful for all the reasons that motivated the (effectively abandoned) MIDI API.

There are no higher-level APIs that offer low-latency access to MIDI controllers, and no reason to think that that will change any time soon.

[7ombie]

It is worth noting that, while the spec for the WebMIDI API contains non-normative sections that explicitly mention Launchpads and DJ controllers, the normative parts of the specification state that the API is only available in the main thread (and there is no intention to change that, despite many of us wishing that there was).

Given that the main thread will never provide the low-latency responses that realtime MIDI requires, this spec should address the fact that the WebMIDI spec simply does not provide support for USB-MIDI controllers.

USB-MIDI controllers are an important USB device class that is effectively unsupported by the Web, so I'd be grateful if the maintainers of this API would reconsider this specific nuance of the blacklist.