Auto-Connect of Outputs after WebMidi.enable()?

[qm210]

Hey everyone,

got a question about whether this behaviour is intentional. I got a single output device and it seems that every time, WebMidi.enable() starts with that output state = "connected". I can then call close() and restart the application, and will again have that output "connected".

Is that expected? Is that even something under the control of WebMidi? it would seem more natural to me to start with all-disconnected outputs (and inputs) - also, would that auto-connect all outputs?

tested from a current Chrome (Windows).

best,
qm210

[djipco]

This is the expected behaviour. WEBMIDI.js takes care of opening (and closing) ports for you. In fact, the Web MIDI API spec does not even require you to open an output port before sending to it because it will implicitly open it for you. The same goes for an input port. As soon as you attach a listener to it, the port is automatically opened. So, basically, you shouldn't worry about opening or closing ports.

[ClosetGeek-Git]

I'm new to the scene so forgive me if I'm mistaken, but are you saying that all devices are auto-connected by default behavior? If so it should have the option to whitelist/blacklist devices for auto-connecting.

[djipco]

I am using a webview2 object that is set to automatically handle Sysex permission authorization, I'm not receiving any prompt requesting authorization to connect to a device. If the Sysex permission prompt is the strategy for preventing a given device from being auto-connected it's not available in my scenario.

WebViews are a special case because, as you said, they can be configured to allow things that would not be allowed by default in a regular browser. Again, opening a port does not mean that anything is actually happening on the device. It only means that the software layer on the host (your computer), is ready to talk to the device.

[djipco]

Destroying the port on connection event sends WebMIDI into an endless loop as it seems to repeatedly reconnect (and then destroy) the device automatically.

I'm not sure why you would want to destroy the port. This is usually done by the library itself at the very end of a session. If you really want to, you could use close() to close the port but I'm not sure what purpose this serves.

[ClosetGeek-Git]

Only one process is allowed to hold a port at once on Windows, so once you open a port other software is unable to access it. By auto-connecting to all ports webmidi blocks other software from accessing controllers which is intrusive. I also see where the sysex security concern is as well now that I see that this is the case. It not only accesses controllers without an intent from the user but forcefully access all controllers.

[ClosetGeek-Git]

I see that this is a Web Midi API issue, I hope I don't sound critical of your project, by all means it sounds awesome. As soon as I call navigator.requestMIDIAccess() it becomes impossible to access controllers from other software unless the port is already held by the other program, in which case it's not even visible to the web midi api. In my case the host software is initializing plugins before handling it's own midi access, so the webview is getting first dibs and not releasing them.

[ClosetGeek-Git]

I'm not sure why you would want to destroy the port. This is usually done by the library itself at the very end of a session. If you really want to, you could use close() to close the port but I'm not sure what purpose this serves.

close() doesn't release the midi port, it only prevents events from bubbling up to the user. That's not closing it, that's ignoring it.

[djipco]

close() doesn't release the midi port, it only prevents events from bubbling up to the user. That's not closing it, that's ignoring it.

The library simply calls the lower-level MIDIPort.close() method defined by the Web MIDI API specification. The specification explicitly states that, in exclusive access systems (a.k.a. Windows), calling close() should release the port and make it available to other applications.

If you find this not to be the case, the issue should be raised in the bug trackers for Chromium or Firefox. If you do raise the issue with them, please be so kind as to link it here for follow up.

[djipco]

I see that this is a Web Midi API issue, I hope I don't sound critical of your project, by all means it sounds awesome. As soon as I call navigator.requestMIDIAccess() it becomes impossible to access controllers from other software unless the port is already held by the other program, in which case it's not even visible to the web midi api. In my case the host software is initializing plugins before handling it's own midi access, so the webview is getting first dibs and not releasing them.

This is an interesting observation. Are you saying that, as soon as you call navigator.requestMIDIAccess() in vanilla JavaScript on Windows (without explicitly opening the ports), the ports become unavailable to other apps? If that's the case, I'm afraid there isn't much I can do at the library level.

[djipco]

Only one process is allowed to hold a port at once on Windows, so once you open a port other software is unable to access it. By auto-connecting to all ports webmidi blocks other software from accessing controllers which is intrusive.

I see your point here. I mostly work on Mac OS and GNU/Linux so I haven't really stumbled upon that issue before. I looked at the code and I don't think it would be too hard to make the opening of the ports optional (barring any unforeseen side effects).

Since the library attempts to make it easy to use MIDI on the web, it would still open the ports by default but I could add an option to the WebMidi.enable() method to modify the default behaviour. Something like:

WebMidi.enable({openPorts: false});

I would then have to decide whether calling send() on an output port automatically opens the port and sends the message (this is the Web MIDI API default behaviour) or if it should just throw an error. The same goes for inputs. When attaching a listener, is the port automatically opened or does it throw? I would be leaning on following the spec's lead.

[ClosetGeek-Git]

Yes, navigator.requestMIDIAccess() make all ports become unavailable. I'm in a fairly one off circumstance:

1. the host software uses midi to to connect to what are basically control surfaces
2. my plugin uses RtMidi to connect to midi hardware outside of Javascript
3. Javascript is running within a system webview that is "chromium based" (Edge) but has some of it's own bells and whistles outside of mainline chromium implementations of some Web standards. This may be a bug in their implementation, especially considering the webview2 has it's own way of handling Sysex automatically. There's no options/flags that could introduce user error. This is the snipplet where Sysex is allowed without user interaction, as seen in the second if

  HRESULT STDMETHODCALLTYPE Invoke(ICoreWebView2 *sender, ICoreWebView2PermissionRequestedEventArgs *args) {
    COREWEBVIEW2_PERMISSION_KIND kind;
    args->get_PermissionKind(&kind);
    if (kind == COREWEBVIEW2_PERMISSION_KIND_CLIPBOARD_READ) {
      args->put_State(COREWEBVIEW2_PERMISSION_STATE_ALLOW);
    } 
    if (kind == COREWEBVIEW2_PERMISSION_KIND_MIDI_SYSTEM_EXCLUSIVE_MESSAGES) {
      args->put_State(COREWEBVIEW2_PERMISSION_STATE_ALLOW);
    }    
    if (kind == COREWEBVIEW2_PERMISSION_KIND_AUTOPLAY) {
      args->put_State(COREWEBVIEW2_PERMISSION_STATE_ALLOW);
    }
    if (kind == COREWEBVIEW2_PERMISSION_KIND_FILE_READ_WRITE) {
      args->put_State(COREWEBVIEW2_PERMISSION_STATE_ALLOW);
    }
    if (kind == COREWEBVIEW2_PERMISSION_KIND_WINDOW_MANAGEMENT) {
      args->put_State(COREWEBVIEW2_PERMISSION_STATE_ALLOW);
    }
    return S_OK;
  }

If I include navigator.requestMIDIAccess() within Javascript I see the following outcome:

1. the host's GUI states it's unable to connect to it's primary controller, a Numark N4 Midi controller. If I close the webview window (destroying Javascript) it connects.
2. RtMidi throws an exception when I try to connect to a second controller, an Akai APC40, within my plugin outside of the Javascript environment. When I destroy Javascript it connects,

I'm going to start removing layers to see if I can make the behavior stop then follow up where most appropriate.

[djipco]

That's all very interesting. Thanks for reporting.

I'm not sure why navigator.requestMIDIAccess() makes all ports unavailable. As far as I can tell, the section of the Web MIDI API specification concerned with requestMIDIAccess() does not mention how port exclusivity should be handled. I'm guessing they wanted to leave that open depending on the platform.

If you are so inclined, you could bring it to the attention of the Web Audio Working Group by creating an issue in the Web MIDI API spec repo.

As far as the library is concerned, I will be leaving things as they are for now. However, if it ever becomes possible to call navigator.requestMIDIAccess() without systematically blocking access to all ports, I will gladly add a way to control which ports are automatically opened (or something similar).

Keep me posted!