[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 #26 from Jussi Kalliokoski <jussi.kalliokoski@gmail.com> 2012-09-10 10:10:34 UTC ---
(In reply to comment #24)
> 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.

I laughed out loud, but the analogy doesn't really fit. ^^

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

I've yet to see a demonstration that this is a more common case than any other.

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

Performance is always important, no disagreement there, but saving a few CPU
cycles doesn't justify adding an extra method unless there are demonstrated
real world scenarios that suffer significantly from these extra cycles.

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

Florian:
I have to admit, I haven't heard of this before either. Could you elaborate
this a bit? Is this some sort a memory allocation limit (I'd imagine the device
has to be pretty old to not be able to handle its own system dump)? CPU limit
(if so, I'd think that the device would just become unresponsive for a while)?

And how would one really counteract this, how do you know what size of chunks
to send and how often? After all, based on your explanation it would appear
that different devices have different limits? I also wonder how the devices
handle the dump when it's complete if they can't handle it if it's sent as a
whole...

Thanks for your input!

-- 
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 10:10:40 UTC