Open Bug 1802149 Opened 2 years ago Updated 6 months ago

Add hot-plug support for MIDI devices

Categories

(Core :: DOM: Device Interfaces, task)

Product:
Core
Component:
DOM: Device Interfaces
Type:
task

Tracking

()

People

(Reporter: gsvelto, Unassigned)

References

(Blocks 1 open bug)

Details

Currently midir does not support hot-plugging MIDI devices and thus neither do we. The right solution is obviously to add support to upstream midir and then pull the required changes. If we need a quicker fix I guess that polling (cringe) for devices every second could also do the trick.

At the moment it appears that the system's MIDI devices are only enumerated at browser startup. Reloading the tab/page does not update the list of devices, the entire browser needs to be quit and started again. Maybe this wold be possible to fix until hotplug support arrives?

Kay, what OS and OS version are you using?

Flags: needinfo?(kay)

The list of current devices does not get updated on tab reload on MacOS (13.0.1).

Sorry for not checking, I assumed it is the same behavior on all platforms. On Windows and Linux updating the current device list seems to work fine when the tab is reloaded. I'm testing with: https://versioduo.com/webmidi-test/

Flags: needinfo?(kay)

(In reply to Kay Sievers from comment #3)

The list of current devices does not get updated on tab reload on MacOS (13.0.1).

Adding a data point:

We're seeing the same behaviour with at least a macOS 12.6.1 M1 MBP with the latest FF Beta. The browser doesn't pick up device changes until restarted. We're testing with https://components.novationmusic.com but also https://pixelpoke.de/midireporter (the latter not supporting hotplugging anyway, but it should refresh on reload).

I need to update the Rust crate we use for interacting with the MIDI devices as we're several versions behind upstream. I hope that it's just a problem with what we currently have in the codebase and updating will solve it; otherwise I'll look for a solution myself.

Hi,
Any update on when hotplugging might be supported?

We currently use WebMIDI on Chrome/Edge/Opera/Brave to perform a firmware update process, using SysEx calls.
This includes switching the connected device into a bootloader mode before transmitting the firmware, and this is reliant on the 'onstatechange' event working correctly, as they appear as different USB/MIDI devices. For this reason, it currently silently fails on Firefox, as we get no event to indicate that the device switch has occurred

We're going to have to try and add code to detect the browser agent and disable the process specifically for Firefox, as the availability of the feature is currently dependent on the MIDI Access returned from 'requestMIDIAccess', which is obviously still 'true' for Firefox. We'd really prefer not to do this, but obviously feature detection isn't possible in this scenario.

The 'requestMIDIAccess' allows the passing of a MIDIOptions object, which we use to confirm SysEx support, so ideally, if hotplugging is not supported, it would be better if MIDIOptions had been expanded to include a boolean indicating whether it is available, which could be used for feature detection.

Waking up this one, any chances to see this implemented in the near-term. We'd be happy to help testing it.

--

We're also using WebMIDI for firmware updates and as our Linux (desktop-os) users tend to run Firefox, we would really like to add Firefox as a supported browser (incl. on Windows). ps. we dont' want to require people to install other (less private) browsers just for this feature.

Like reported by other companies above, this is a blocker as it also prevents usb-midi-device state-changes from promoting, i.e. connect device-x, it shows up, user connects device-y, no updates, only the first device is present... even asking for midi permissions again makes no difference.

We've been using the midir crate under the hood since we didn't have the resource to implement a full backend on our own. Unfortunately midir does not support hot-plug just yet. At the moment we're stretched too thin to contribute it ourselves. I might be able to cook up something at the DOM level, maybe via polling, but that wouldn't be pretty.

not knowing midir, is it this lib?
https://github.com/Boddlnagg/midir/issues/78

looking at their issue-tracker, maybe there are other alternatives?
doesn't seem impossible for midir to fix it though on mac and linux

any chance of merging vincent's fix?

I don't know if we can integrate that with our existing code but I'm pretty sure we can add our own polling since we already have I/O threads to do that. The issue here is not feasibility - this is feasible - but finding the time to do it. ATM I'm swamped with other stuff.

I just ran into this, too. I'd expect a statechange event on the MIDIAccess interface when a new MIDI device is connected.

Looks like Bug 1798742 and Bug 1805593 are duplicates of this one?

Duplicate of this bug: 1805593
You need to log in before you can comment on or make changes to this bug.