Sequence of events for enable and connected

[glend1]

as mentioned in #211 you've changed how enable() works, I think the following is a very unreadable piece of code;

WebMidi.addListener("connected", connected);
WebMidi.addListener("disconnected", disconnected);
WebMidi.enable().catch((err) => {
    console.log(err)
})

it implies, to me, that we already have midi if we can add listeners to them. I am not sure if standard javascript does this with its events (onClick, onFocus, onHover, onKeypress) i believe the elements/api's have already been loaded by the time we attempt to attach events to them.

Instead it seems to me that midi is already loaded and we are just granting permission to the browser. (by the way, I don't get a popup asking me to grant permssion in chrome, i might have selected "always remember" and forgot but this seems weird too (not saying you have control over this))

Additionally, If i was opening a DB connection i would expect to open a connection before I could use it.

Out of curiousity, I omitted the enable() line to see what would happen and nothing happened (expectedly) I feel this is another reason this is a usability concern because (unless we have function calls or some asynchronous stuff happening) this isn't how normal procedural programming works, statements do not depend on statements that follow it.

This seems very counter intuative. Do you agree? I think to be more descriptive if enable() were renamed to requestMIDIAccess() so that it follows javascript standard. Even then I still don't think this is very readable, for the reasons i've stated.

[djipco]

I understand your point.

Let me provide a little context. The WebMidi object is a singleton that's already instantiated when you use it. So, I don't see a problem adding a listener to an already-existing object. The enable() method enables MIDI by connecting to the host's MIDI subsystem. When it does that, all inputs and outputs are retrieved and their connected events are fired. So, if you want to react when an input or output is connected, you need to add listeners beforehand.

In version 2.x, I was purposely delaying connected events so the developer could add a listener after MIDI was enabled. This didn't feel right. I much prefer dispatching events when they are really happening.

As far as I'm concerned, I prefer to enable the library and then add listeners for connected and disconnected devices. If I want to know which devices were already connected, I just have to look at the WebMidi.inputs and WebMidi.outputs arrays:

WebMidi.enable().then(e => {

  // Available inputs and outputs can be retrieved immediately
  console.log(WebMidi.inputs, WebMidi.outputs);

  // I can also watch for newly connected or disconnected devices from this point onward
  WebMidi.addListener("connected", e => console.log(e));
  WebMidi.addListener("disconnected", e => console.log(e));

});

This is how I do it. But, if you want, you can also add the listeners earlier.

Having said that, I'm curious to know how you would prefer it to work? Perhaps you have some insights I have not considered.

P.S. As far as renaming enable() to requestMIDIAccess(), I'm afraid it would cause confusion (not to mention backward compatibility issues). People already confuse the Web MIDI API and the WEBMIDI.js library.

[glend1]

I might test the MIDI API and see how implimentation differs but i think it should work as closely to the original spec as possible.