search

electron / electron

:electron: Build cross-platform desktop apps with JavaScript, HTML, and CSS
https://electronjs.org
MIT License
114.23k stars 15.4k forks source link

Add Support of Windows 10 + 'WinRT MIDI API' via commandLine.appendSwitch #17073

Open andrejhronco opened 5 years ago

andrejhronco commented 5 years ago

Is your feature request related to a problem? Please describe. Prior to Windows 10, it wasn't possible to use more than one piece of software simultaneously connected to a MIDI device, for example a DAW and a MIDI device editor program. Windows 10 has a new MIDI API that developers can use which allows multiple pieces of software to simultaneously connect to a MIDI device, macOS has always allowed this...The only snag in this new Windows API is that all software needs to be using the new API for it to work, so both DAW and Editor need to use it. This can be enabled in a browser, which supports the Web MIDI API, via chrome:flags

Describe the solution you'd like Since this has been supported in Chrome for a few years now, it would be great to add support for this flag as well in Electron.

Describe alternatives you've considered There doesn't appear to be an alternative solution using Electron

Additional context The flag is: use-winrt-midi-api set to enabled: app.commandLine.appendSwitch('use-winrt-midi-api', 'enabled')

andrejhronco commented 5 years ago

Hello, Just wanted bring up an additional use case to add this to the flags Electron supports. It turns out that there is a nasty bug with the non-WinRT MIDI system where MIDI device disconnects / reconnects can lock up Electron resulting in needing to force quit the app. Thank You and looking forward to continue building Web MIDI apps in Electron.

nicross commented 4 years ago

Echoing the need to support this API. Just spent some time debugging an issue with my Electron 9.x app not recognizing any MIDI inputs on Windows despite them being available in Chrome 83 (with the flag enabled). Turns out that by running them simultaneously I needed to close my browser tab for Electron to see them. Silly mistake, but it's another way to reproduce this issue. 🤦

marcelblum commented 3 years ago

+1. It would be nice to not have this impediment where we can't detect a MIDI device just because another open app happens to have already accessed it at some point in its lifetime. The requestMIDIAccess() API does not gracefully handle this situation, rather it just excludes the device from the returned device list if it's already in use elsewhere, which can be frustrating if you don't know why (e.g. "why can't this app see my connected device argh!").

dopry commented 2 weeks ago

+1 this is a critical feature for those of us using midi in electron. It is a major usability issue for our applications.

Is https://github.com/electron/electron/blob/main/shell/common/options_switches.cc where I need to add the switch to make it work? Here is the flag in chromium https://github.com/search?q=repo%3Achromium%2Fchromium%20kMidiManagerWinrt&type=code

dopry commented 1 week ago

Look like winMM will remain the default in chromium for another year, https://issues.chromium.org/issues/361126126. This is an issue because the winMM midi manager will only report one device if you have two identical devices. WinMM will not have as robust of an integration with the new Window Midi services as winMM, https://devblogs.microsoft.com/windows-music-dev/windows-midi-services-oct-2024-update/, and WinMM takes exclusive locks on midi devices so once claimed by chromium/electron they are no longer available to other software and vice versa.