Closed jussi-kalliokoski closed 11 years ago
Original comment by Jussi Kalliokoski on W3C Bugzilla. Wed, 05 Sep 2012 09:58:02 GMT
Fair enough. Actually what I want to do right now with this and Bug 18764 is to shrink the MIDIMessage interface to just contain the timestamp and the data, status and channel being the first byte. Thoughts? I'm also thinking of a way to make the MIDIMessage interface a dictionary instead.
In that case we'd have
sendMessage(firstByte, secondByte, thirdByte, ...)
and the longer version for more complicated messages:
sendMIDIMessage({ timestamp: performance.now() + 1234.0, data: new Uint8Array([firstByte, secondByte, thirdByte, ...]) })
How's that sound?
Original comment by Jussi Kalliokoski on W3C Bugzilla. Wed, 05 Sep 2012 12:15:08 GMT
Proposed changeset: https://dvcs.w3.org/hg/audio/rev/bf0e920450e6
Original comment by Chris Wilson on W3C Bugzilla. Wed, 05 Sep 2012 17:20:43 GMT
LGTM.
Original comment by Florian Bomers on W3C Bugzilla. Wed, 05 Sep 2012 19:31:07 GMT
just asking: doesn't the syntax allow you to define:
void sendMessage(DOMHighResTimeStamp timestamp, short status, short... data)
Then we could have a timestamp for the convenience "send" method, and a variable length message. Set timestamp to 0 to send it immediately.
Original comment by Olivier Thereaux on W3C Bugzilla. Thu, 20 Sep 2012 06:59:30 GMT
Hearing no objection after over a week, closing.
After reviewing carefully the use in practice, as well as historical usage from the Windows MIDI APIs, I believe the sendMessage() "short message shortcut" should not have a timestamp, in order to allow a variable length short message. (From status-byte-only to typical 3-byte messages.)
The Windows method doesn't have this, and the overhead of using sendMIDIMessage(createMIDIMessage()) is actually not very large if you DO want the timestamp.