- 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