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

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

          Priority: P2
            Bug ID: 19975
          Assignee: dave.null@w3.org
           Summary: Promote data and timestamp onmessage/MIDIEvent, get
                    rid of MIDIMessage altogether?
        QA Contact: public-audio@w3.org
          Severity: normal
    Classification: Unclassified
                OS: All
          Reporter: cwilso@gmail.com
          Hardware: All
            Status: NEW
           Version: unspecified
         Component: MIDI API
           Product: AudioWG

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.

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

Received on Friday, 16 November 2012 00:07:07 UTC