18762 2012-08-31 22:43:30 +0000 MIDIOutput.sendMessage doesn't need a timestamp 2012-09-20 06:59:30 +0000 1 1 1 Unclassified AudioWG MIDI API unspecified PC All CLOSED WORKSFORME P2 normal TBD 1 cwilso dave.null jussi.kalliokoski olivier.thereaux w3c_bugz public-audio oldest_to_newest 73121 0 cwilso 2012-08-31 22:43:30 +0000 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. 73216 1 jussi.kalliokoski 2012-09-05 09:58:02 +0000 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? 73221 2 jussi.kalliokoski 2012-09-05 12:15:08 +0000 Proposed changeset: https://dvcs.w3.org/hg/audio/rev/bf0e920450e6 73239 3 cwilso 2012-09-05 17:20:43 +0000 LGTM. 73254 4 w3c_bugz 2012-09-05 19:31:07 +0000 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. 74116 5 olivier.thereaux 2012-09-20 06:59:30 +0000 Hearing no objection after over a week, closing.