W3C home > Mailing lists > Public > public-audio@w3.org > July to September 2012

[Bug 18764] New: MIDI messages don't all have a channel, and status should be part of data.

From: <bugzilla@jessica.w3.org>
Date: Fri, 31 Aug 2012 22:51:09 +0000
To: public-audio@w3.org
Message-ID: <bug-18764-5429@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18764

           Summary: MIDI messages don't all have a channel, and status
                    should be part of data.
           Product: AudioWG
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: MIDI API
        AssignedTo: dave.null@w3.org
        ReportedBy: cwilso@gmail.com
         QAContact: public-audio@w3.org


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.

-- 
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 Friday, 31 August 2012 22:51:10 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 31 August 2012 22:51:10 GMT