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

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

From: <bugzilla@jessica.w3.org>
Date: Thu, 06 Sep 2012 13:09:19 +0000
Message-Id: <E1T9bpf-0007Q0-2z@jessica.w3.org>
To: public-audio@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18764

--- Comment #11 from Chris Wilson <cwilso@gmail.com> 2012-09-06 13:09:18 UTC ---
I don't think I've made the point correctly.

For a large number of arguments, variadic args aren't great, because each arg
has to be pushed on the stack; it's better to push a single pointer to an array
of data, particularly typed arrays (like UInt8) in Javascript.  This isn't
"just a compiler issue" - it's how the code is structured, and it's the API
designer's responsibility to make an informed choice between variadic args
(which are necessary for some APIs, like printf() for example0) and passing
array references and/or having optional arguments.

MIDI really does have two types of messages - sysex, which are variable length,
and everything else, which are 1-3 byte long messages.  The latter are the vast
majority of messages.  I believe we should optimize the API around those two
cases.  The underlying APIs are optimized around them.  

Please do not use variadic arguments to make the simple send() able to send
arbitrary bytes.  Using optional arguments for a total of three bytes of
arguments is a more appropriate choice.  Otherwise, the data will need to be
inspected not only for length, but for partial messages as well, and we will
need a lot more error returns to explain to users how they've violated MIDI
protocol.  We need to think in complete MIDI messages in the API; this isn't
just an arbitrary serial port.

As for multiple MIDI messages batched together - yeah, we could do something
similar to that.  CoreMIDI effectively does this, since send() takes a
packetlist; however, their packetlists have a significant overhead to creating
and managing.  If we want to take that on, we should simply overload send to
have:

send( short status, optional short data1, optional short data2)
send( MIDIMessage msg )
send( <sequence> MIDIMessage msgs );  // I think this is legal; need to dig in
a bit more.

Again - I think variadic is the wrong choice here.

-- 
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 Thursday, 6 September 2012 13:09:25 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 6 September 2012 13:09:25 GMT