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: Sat, 08 Sep 2012 08:25:10 +0000
Message-Id: <E1TAGLm-0000VO-5y@jessica.w3.org>
To: public-audio@w3.org

--- Comment #17 from Florian Bomers <w3c_bugz@bome.com> 2012-09-08 08:25:07 UTC ---
Chris, I see your points (except the "software protocol", but that's OT). But I
still don't understand why all that excludes a variadic method signature. It's
a superset of what you propose.

For purpose of illustration some of the points Jussi and I made, a simple
Windows implementation could look like this (again, free syntax):

function sendMessage(short status, short... data) {
  if (data.length <= 3) {
    midiOutShortMsg(hmo, (data[0] << 16) | (data[1] << 8) | data[2]);
  } else {
    this.sendMIDIMessage({data: new Uint8Array(data)});

(of course, special case handling for length = 2, 1, or 0 will always need to
be added)

So for performance, it'll be OK -- there is only a tiny bit more overhead for
va_args init (which is done by compiler magic), and for one conditional.

For programmer's convenience it's the same as the non-variadic form, plus
allowing you to send long messages in a convenient form, too.

For API specification and implementation, it does not add any difficulty,
because there is already a way to send "arbitrary" variable length messages.
It's necessary to define how these "arbitrary" should look like anyway, e.g.
"One single MIDI message".

And as Jussi points out in different words: just because short messages are
usually sent much more often than sys ex messages, it does not mean that a
programmer will type a command for sending a short message more often.

My conclusion is that nowadays there is no technical reason to use different
methods for sending/receiving short and long MIDI messages. Because you can do
both with the same method. There is a ton of Windows software that does not
handle Sys Ex because the API makes it so difficult to use it (for historically
valid reasons). Here we have the chance to make it better.

Maybe Jussi's send() function signature will suit us both? The underlying
implementation can easily optimize it for short messages...

And all this is just a couple of cents from me. I want to assist, not

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 Saturday, 8 September 2012 08:25:11 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:50:02 UTC