- From: <bugzilla@jessica.w3.org>
- Date: Wed, 05 Sep 2012 09:48:22 +0000
- To: public-audio@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18764 Jussi Kalliokoski <jussi.kalliokoski@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jussi.kalliokoski@gmail.com --- Comment #1 from Jussi Kalliokoski <jussi.kalliokoski@gmail.com> 2012-09-05 09:48:22 UTC --- (In reply to comment #0) > After looking at all the MIDI messages, including sysex, and examining the > other MIDI APIs out there, I don't think we should break out the status and the > channel separately in sendMessage(), and I also don't think we should break out > status and channel from the rest of the data in a MIDIMessage. > > For the first point - Windows API names the first byte "status", but packs them > all into a dword, and doesn't break channel apart; CoreMIDI uses MIDIPackets, > which contain pure data (i.e. they don't distinguish status bytes from any > other bytes; in fact, it does not even appear to be a requirement that there > only be one MIDI message per packet, just that the packets contain complete > MIDI messages.) > > For the second point, when forwarding the data on to the underlying APIs, you > will need the status byte as part of the data; it would be considerably easier > to have it all together, and not significantly harder to access data[0] instead > of status in MIDIMessage. At any rate, MIDIMessage should definitely not have > a channel. This is something I've been thinking about as well. It should be simple enough to separate the status and channel manually: var status = 0xF0 & firstByte var channel = 0x0F & firstByte And merging them is even less of a hassle. I think it might be a good idea to just stuff this information into a single byte, as is intended in MIDI anyway. Unless there are objections, I will make the necessary changes to the spec soon. -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Wednesday, 5 September 2012 09:48:23 UTC