[Bug 19762] "connect" event not logically possible, and disconnect message not present on some systems

https://www.w3.org/Bugs/Public/show_bug.cgi?id=19762

--- Comment #6 from Jussi Kalliokoski <jussi.kalliokoski@gmail.com> ---
Oops, thought of this one so much that I forgot that I hadn't actually
answered.

(In reply to comment #3)
> First, my apologies for brusquely removing; I've had feedback that the more
> implementable the spec is, the easier it is to get implementation experience.
> 
> My comment on disconnect being challenging on some underlying platforms was
> referring to the fact that not all underlying systems fire disconnect events
> (e.g. Windows' MIDI API, outside of the apparently-deprecated DirectMusic
> APIs).  Although of course if you already had a reference to a MIDIPort, and
> it was disconnected then reconnected, you could get a connect event fired on
> the MIDIPort (see #2 in Comment 1 - "optionally additionally fire on
> MIDIPort itself".  However, that's frankly quite a narrow scenario, and it's
> more interesting to be able to get notifications for Ports you don't already
> have a reference to - e.g. to update a dynamic list of currently available
> MIDI ports, detect when a new controller has been plugged in, etc.  That
> would be much more of a core usage scenario for a connect event.

I think that both of those cases (detect when a device is newly plugged in and
detect when a device is replugged) are quite useful. I don't know about you,
but for me it's about every other day that I setup my DAW and a virtual
instrument just to notice that I forgot to plug in the MIDI keyboard (I don't
exactly have a dedicated computer for making music), so I'll have to restart my
DAW and either save my progress before it to keep going from where I left or do
the setup again after the DAW is back on. Not such a great UX, and this is the
norm (I honestly haven't used a single DAW that worked differently, but then
again I have all my DAWs on Windows) when the APIs don't have a good way of
detecting these things.

As for the hot-plugging scenario, ever used a DAW on a gig for the synth, then
someone accidentally unplugs your USB cord with a guitar headstock and then
that buildup just doesn't sound quite right without the synths, since you have
to wait for the DAW to restart? Happened to me, and it's quite an embarrassing
experience, really. As for the less embarrassing but still annoying and
probably more common ones: you've setup your DAW (again) on a gig or at
rehearsals and then that keyboard just isn't in the right place according to
someone so you have to move your stuff and again we go with restarting the DAW
(unless you were smart enough to prepare and didn't wire the keyboard through
the stand, which however does make the first scenario more likely).

This really is the sort of thing you want the API to make easy for you so that
most applications out there just work in these situations.

> As to "not going to magically disappear" - I don't know, honestly; we have
> to explicitly define what happens in this case.  Would it be expected that
> the MIDIPort becomes "active" again (e.g. you start receiving messages on an
> Input, or you can once again send to an output) if it's unplugged and then
> replugged?  I haven't had a chance to investigate behavior in that scenario
> in Windows/CoreMIDI.

Yes, this is how I've planned it.

> On merging connect/disconnect updates - I'm a little uncomfortable with
> that; it's  much easier to write code that detects and configures a
> newly-plugged controller, e.g., if you're told WHICH Port was added.  We
> could require the developer to hold on to the list themselves (i.e. there is
> a workaround), but it might be easier to provide this information in the
> first place.

Hmm. I doubt that the application doesn't already know all the relevant
information about ports it's already using, so I think the listener for the
event for MIDIAccess to notify about the list of available ports changed will
mostly just scan the lists again to see if there are any devices that have a
function reserved for them, but aren't assigned to that function yet. The event
firing even when ports get disconnected is mostly useful to e.g. update a list
UI to for picking the right port.

> If we are going to have these events, and are expecting polling to be used
> to implement them in a significant scenario (e.g. "on Windows"), we really
> do need to say something about such things as the latency of these events. 
> Polling every MIDI device in the system once a second to implement these
> events seems not necessarily worth it to me; but if we are doing that, we
> need to provide definitive guidance on this, and these events should be a
> "MUST" not a "SHOULD".

Agreed. On systems that require polling, I doubt that it makes sense to poll
more often than once every 15 seconds or so.

> For all these reasons, I personally think we should postpone connection
> events to a later revision; but if you want to try to address this now I'm
> open to doing that.  However, what we had in there wasn't very useful, and
> it opened up more questions than it resolved.

You're right about the previous text not being very helpful, but I'd still like
to pursue this. While we should learn from other MIDI APIs and it's true that
the underlying APIs and many wrapper APIs have no support for this feature
(without polling or other nasty solutions), I think in this case the thing to
learn is to not repeat the mistake.

Personally, as a developer, I find it annoying that those features aren't there
without jumping hoops. As a user, I find it annoying, because it affects the UX
of programs I use. And allow me to use a lame joke here: "I'm glad the APIs
don't let me know when relevant devices are plugged in" - No one, ever. I can't
think of a single argument for not having these features in, from the API
usability perspective, or from the user's perspective. Implementors'
perspective, sure, any feature costs precious man-hours in implementation,
tests, code review, QA and fixing bugs. However, this isn't especially complex
to implement. Jumping hoops, sure, but I doubt that it even makes the list of
95% of the hardest web features to implement.

> The changelists (there are actually two, as I missed a section in my first
> update) are pretty easy to grab content from and push back in:
> 
> https://dvcs.w3.org/hg/audio/rev/46c470599a4b and
> https://dvcs.w3.org/hg/audio/rev/b70563d39ab1
> 
> You can revert them, but then these issues need to get resolved in detail at
> the same time, and I maintain that the current text's structure
> (connect/disconnect fire on MIDIPort, not MIDIAccess) is not addressing the
> most important use case (updating list of accessible ports).

Meh, don't worry about it, I'll need to write new text for it anyway. I was
just surprised of the move without having myself had the time to reply to the
argument made.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Monday, 19 November 2012 21:45:40 UTC