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 06:05:55 +0000
Message-Id: <E1T9VDv-00041n-IF@jessica.w3.org>
To: public-audio@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18764

--- Comment #10 from Jussi Kalliokoski <jussi.kalliokoski@gmail.com> 2012-09-06 06:05:55 UTC ---
(In reply to comment #9)
> thanks for commenting, Chris. I do not follow, though: I see this as an
> opportunity to create a MIDI API that makes sense in terms of MIDI and not in
> terms of how the API will be implemented underneath. The Windows MME API was
> created about 20 years ago when memory management and software interrupts were
> the main issues for realtime MIDI handling.
> 
> It's easy for the underlying implementation to inspect the data passed to the
> sendMessage() method and use the appropriate OS API function. It should be done
> for the sendMIDIMessage() variant, too.
> 
> At the core, MIDI is a serial protocol. It just transmits one byte after
> another. I do not see a reason to force API users to separate short messages
> from long messages. It is very convenient to send multiple short messages at
> once. And for the given examples, one "message unit" really consists of
> multiple 3-byte MIDI messages.
> 
> Regarding your second point: do you say that the performance of a "variadic"
> method is worse than creating an object with an array and passing that to a
> non-variadic method? That could be a reason to not use "variadic". But isn't it
> just a compiler issue?
> 
> For dynamic messages, and for received messages, the MIDIMessage approach is
> nice. But for sending (mostly) hardcoded messages, using var args is very
> appealing.

I'd think that if the underlying implementation has an additional branching
operation to check the amount of arguments sent (which it probably has to do
anyway) and optimizes for three, it's a ridiculous performance loss in this
kind of an API, and not really something we should worry about in this case.

Thanks Chris for pointing me to the variadic arguments, I'm going to change the
signature for the next update.

-- 
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 06:05:56 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 6 September 2012 06:05:56 GMT