[Bug 19975] Promote data and timestamp onmessage/MIDIEvent, get rid of MIDIMessage altogether?

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

--- Comment #11 from Jussi Kalliokoski <jussi.kalliokoski@gmail.com> ---
(In reply to comment #9)
> I like the proposal of getting rid of MIDIMessage. I can't access the
> prototype spec (server problem?), but will try again tomorrow to review it.

The repo hosting seems to be down for me, too.

But to the point:

(In reply to comment #8)
> Hmm, I see. I'm not sure if letting the MIDI implementation increase the
> granularity like that is a plus or a minus; you should be able to drive
> multiple messages through before releasing, anyway.

Here's the thing, it's a tradeoff. There's really no right or wrong choice
here, and I'm not sure of my own preference, but I want us to make that
decision informed:

The single message per event model is far simpler, both in terms of
implementation and usage. However, simplicity is often a tradeoff for power and
in this case both in terms of implementation and usage. From the
implementation's point of view because it allows the implementation to take
some liberties to optimize CPU usage (hopefully for the good, would be sad to
see an implementation as unreliable as setTimeout for example), although not
necessarily very significant ones.

As for the (API) user, in the case that things don't go as planned (a re-layout
takes a significant amount of time, blocking messages), you have better tools
to recover from the situation; you have more information at hand. You can
detect if e.g. you missed a noteon as well as its corresponding noteoff, and
react to that in the way you want, for example by not playing back that note,
but still recording it to a MIDI file anyway. In the single event model you
don't know about the other messages you already missed so you'll probably play
a weird stub of a sound, off its mark.

For the API user, the complexity overhead is never to be underestimated, and in
this case it would be, at best, wrapping your MIDI message handler in a loop,
i.e. another level of indentation, at worst, you can choose to implement
countermeasures for missed messages.

Now if we were designing this API for a (relatively) safe environment (e.g. a
worker), the choice would be easy, but instead this API is most likely to be
used in an extremely unstable environment, the browser main thread.

So, what's it going to be? Like I said, I'm unsure.

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

Received on Monday, 3 December 2012 18:26:18 UTC