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: Wed, 05 Sep 2012 20:56:48 +0000
Message-Id: <E1T9MeW-0004AM-4b@jessica.w3.org>
To: public-audio@w3.org

--- Comment #9 from Florian Bomers <w3c_bugz@bome.com> 2012-09-05 20:56:47 UTC ---
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

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 Wednesday, 5 September 2012 20:56:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:03:11 UTC