search

djipco / webmidi

Tame the Web MIDI API. Send and receive MIDI messages with ease. Control instruments with user-friendly functions (playNote, sendPitchBend, etc.). React to MIDI input with simple event listeners (noteon, pitchbend, controlchange, etc.).
Apache License 2.0
1.54k stars 115 forks source link

not receiving initial connected event for an output port #24

Closed belm0 closed 6 years ago

belm0 commented 6 years ago

I have a MIDI controller which happens to also posses an output port for configuration.

When I enable WebMidi I only receive a connected event for the input port. Subsequently disconnecting the device, I do received disconnected events for input & output, and again receive both when I reconnect.

Following is logging of WebMidi events.

[enable WebMidi with device already connected]
{timestamp: 74.58000000000001, type: "connected", id: "-1075253572", manufacturer: "AKAI", name: "MPKmini2", …}id: "-1075253572"input: Input {_userHandlers: {…}, _midiInput: MIDIInput, …}manufacturer: "AKAI"name: "MPKmini2"timestamp: 74.58000000000001type: "connected"__proto__: Object

[disconnect device]
{timestamp: 2325.8300000000004, type: "disconnected", id: "-1075253572", manufacturer: "AKAI", name: "MPKmini2"}id: "-1075253572"manufacturer: "AKAI"name: "MPKmini2"timestamp: 2325.8300000000004type: "disconnected"__proto__: Object
{timestamp: 2327.4900000000002, type: "disconnected", id: "898669612", manufacturer: "AKAI", name: "MPKmini2"}id: "898669612"manufacturer: "AKAI"name: "MPKmini2"timestamp: 2327.4900000000002type: "disconnected"__proto__: Object

[reconnect device]
{timestamp: 39933.12, type: "connected", id: "898669612", manufacturer: "AKAI", name: "MPKmini2", …}
{timestamp: 39934.82, type: "connected", id: "-1075253572", manufacturer: "AKAI", name: "MPKmini2", …}
djipco commented 6 years ago

@belm0 I was able to reproduce the problem on Chrome 61/Windows 10. It seems to be coming from upstream. I'll have to do more tests to be sure but as far as I can tell Chrome is not firing those events at all... I'll try it on Linux and macOS and see if there's a difference. Which platform are you on?

Thanks for reporting.

belm0 commented 6 years ago

I'm seeing it on OS X Sierra with Chrome 61.

djipco commented 6 years ago

After re-reading the spec and looking at various use cases, I am concluding that it would be more logical if the connected and disconnected events only fired when a device is actually being connected or disconnected. If you load a page while devices are already connected, it should not fire the connected event. There's no real point to it anyway since we can simply look at WebMidi.inputs and WebMidi.outputs to know what's available.

Obviously, if a device is added or removed later on, the events will be fired. I commited a new version which works in this way. Perhaps you can try it and let me know what you think.

P.S. I need to do a few more tests before actually releasing it on NPM.

belm0 commented 6 years ago

The behavior up until now was convenient, since I could just implement the connected event to handle both the case where device is already connected at init and where device is connected afterwards.

Would you share some background on the decision to change semantics?

djipco commented 6 years ago

I totally understand your position. Let me think about it a little...

djipco commented 6 years ago

Okay, I think I found a way to meet your needs. Can you try the new latest committed version to confirm it works for you?

This version triggers connected events for both inputs and outputs.

djipco commented 6 years ago

If you still want some background info, you can check the comments I added for myself in the code.

djipco commented 6 years ago

I have not heard back from OP so I'm going to assume that the fix is satisfactory and close this bug report.

belm0 commented 6 years ago

I was able to confirm this fix finally, thank you.