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

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

Jussi Kalliokoski <jussi.kalliokoski@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jussi.kalliokoski@gmail.com

--- Comment #1 from Jussi Kalliokoski <jussi.kalliokoski@gmail.com> ---
(In reply to comment #0)
> It occurs to me that it would be much simpler to get rid of the MIDIMessage
> object altogether, and promote timestamp and data to be on the MIDIEvent.
> 
> The only thing we're buying by having a separate MIDIMessage type is the
> ability to timestamp each individual message; with Windows underlying, we're
> going to be pushing a single message through at a time anyway, and with
> CoreMIDI underlying, we'll get MIDIPackets, which have one timestamp with
> potentially multiple messages.
> 
> Currently, it's implied (but contentious) that a "message" represents a
> single MIDI message (e.g.: no more than one note-on or note-off message),
> and we deliver an array of messages on a single MIDIEvent.  In the Windows
> MIDI API, messages are delivered one at a time, and are pre-parsed.
> CoreMIDI, on the other hand, passes MIDIPackets, where a single data array
> may contain multiple complete messages (it is required to have parsed them
> to make sure the short messages are completely, but oddly passes them with
> no message boundaries, forcing the app developer to re-parse them).  I have
> a preference for doing the break-this-into-MIDI-messages once, under the
> hood, rather than having to write that break-up code in every single MIDI
> app. (Note: if you want to send "custom data" over MIDI, you can and should
> use sysex messages, as people do today; otherwise, it's not MIDI.)
> 
> I think it best to continue to parse into messages for the JS developer, but
> it seems that a single timestamp per group of messages is sufficient; with
> that in mind, I think the right model is either:
> 
> - a MIDIEvent with a timestamp and an array of data bytes, explicitly
> representing one message - this has no semantic loss from the previous
> design, but may be "chattier" on some systems, as it will fire the event
> system more frequently.
> 
> - a MIDIEvent with a timestamp and a sequence of data sequences - that is,
> an array of arrays of data bytes (i.e., the underlying system is responsible
> for parsing into MIDI messages), so we are effectively sending multiple
> messages, but all with the same timestamp.  This is akin to a MIDIPacket in
> CoreMIDI.  
> 
> Either way, I'm inclined to get rid of MIDIMessage.  I prefer the first
> design, as it's simpler.  Welcome feedback.

Sounds like a great idea, at least in theory! I'd very much like the simplicity
of this. However, the idea of having multiple messages with different
timestamps in the same event was designed with performance as the main concern.
While I'm not deadly concerned with the performance of sending messages as it's
not a proven problem, this is.

Firing events in the browser's main thread is not just suspect to latency
(setTimeout(..., 0) anyone? or rendering tasks blocking the event), but also
quite expensive. On a medium spec desktop, having an event listener for
mousemove updating a text box with the coordinates can take 50% of CPU when the
user is moving the mouse. And browsers throttle the mousemove events. A
sequencer might easily be receiving messages a lot more often than the
mousemove events fire and might even do more expensive things, and I don't even
know how one would start throttling the MIDI events in JS (like you can do for
mousemove) without incurring even more cycles.

The current design, however, allows the UA to be aware of upcoming events ahead
of time and use that information to optimize the amount of events fired and
when they're fired, since the current design doesn't even dictate that the MIDI
messages attached to the event have the same timesamp. This might be crucial to
allow reliable scheduling of for example Web Audio API events related to the
MIDI messages, especially in graphics-heavy sequencer applications.

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

Received on Friday, 16 November 2012 12:20:08 UTC