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: Sun, 09 Sep 2012 08:41:30 +0000
Message-Id: <E1TAd58-0004Zv-QX@jessica.w3.org>
To: public-audio@w3.org

--- Comment #21 from Florian Bomers <w3c_bugz@bome.com> 2012-09-09 08:41:30 UTC ---
(In reply to comment #20)
> I think we'll have to at least check for partial messages. We can allow
> multiple messages [in a single packet], but allowing partial messages will be
> dangerous as the developer is not completely in charge of the order the packets
> are sent in. And I can't see any value in partial messages anyway.

For short messages, I agree. For Sys Ex, it is important to allow partial
messages: many MIDI devices use big Sys Ex dumps (e.g. one single Sys Ex of
100KB), but cannot handle them if sent to them at full speed. Ideally, the MIDI
bytes would need to be throttled for such devices, but sending in timed chunks
of, say, 100 bytes will achieve the same. Or we add API methods to set the send

> > the name suggests that it holds only one. Maybe adopt the CoreMIDI name
> > "MIDIPacket" instead?

fine with me, but "MIDIMessage" works the same to me.

Regarding the "sugar" method (i.e. a method that takes MIDI bytes directly as
parameters): IMHO, it is useful and convenient (especially with var args) and
will save a few CPU cycles compared to sendMIDIMessage().
But not having the sugar method and only provide sendMIDIMessage() will be OK
for me, too -- I feel only a tiny bit of pain when allocating an array and an
object for transmitting 3 bytes :)

> > A shorter send() function name also seems more correct for this reason.

yes, as previously expressed, I like that, too.

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 Sunday, 9 September 2012 08:41:32 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:50:02 UTC