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

https://www.w3.org/Bugs/Public/show_bug.cgi?id=18764

--- Comment #18 from Jussi Kalliokoski <jussi.kalliokoski@gmail.com> 2012-09-08 09:54:12 UTC ---
(In reply to comment #17)
> 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) {
>   va_init(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...

Just to clarify, I'm not suggesting that the function is added to the
specification. I don't think it's a good idea to add something that can be
achieved with six lines of code to an API that's likely to be wrapped by
various libraries anyway.

If it's about how many characters you have to type, I'd be happy to change the
name of sendMIDIMessage() to send(). And drop sendMessage().

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

Please don't be apologetic like that; in the standards process, all input is
welcome and quite necessary actually. ;)

-- 
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 09:54:13 UTC