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: Mon, 10 Sep 2012 00:09:02 +0000
Message-Id: <E1TArYk-0006Re-3S@jessica.w3.org>
To: public-audio@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18764

--- Comment #24 from Chris Wilson <cwilso@gmail.com> 2012-09-10 00:09:01 UTC ---
Florian: my point around this whole conversation has been that any API should
be optimized around its most important and common cases.  You made a statement
that "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."  I
don't agree with that;  or more to the point, I don't think that is the
cause&effect, but I do think programmers will type the code to send a single
short MIDI message far more than they will to send sysex messages.

>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. 

And my crescent wrench makes a pretty good hammer, too.

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

I've maintained all along that I believe we need to have a send method that
takes up to three bytes worth of arguments, and sends it immediately, with as
little mental and programming overhead as possible.  Particularly in the
controllerist world, that is an immensely important use case.  (and yes,
sending as well as receiving.)

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

+1 to Jussi's comment; comments are not interference, just potentially
disagreement.  :)  I'd like to explicitly ask for MORE feedback from developers
using MIDI today on this issue.

Jussi:
>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.

1) I disagree that it's not worthwhile to add a simpler API to skip six lines
of code in a very common use case,
2) I don't agree that the MIDI API is that likely to be wrapped by various
libraries that frequently, either.  Or maybe I'm just considering the authors
of those libraries.

As to the various "performance isn't important here" comments - performance is
always important.  But my point was really intended to be around the mental
overhead of having to create two wrapper objects around three bytes of data.

Florian: are there are devices that choke on their own sysex in a single sysex
packet?  I know of many devices (like my ancient Akai S612 sampler) that have a
handshake protocol in sysex in order to keep from clogging the pipe, but I
didn't remember any that had to have MIDI itself slowed down.

-- 
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 Monday, 10 September 2012 00:09:03 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 10 September 2012 00:09:07 GMT