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:12:24 +0000
Message-Id: <E1TAccy-0003tA-Me@jessica.w3.org>
To: public-audio@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18764

--- Comment #20 from Jussi Kalliokoski <jussi.kalliokoski@gmail.com> 2012-09-09 08:12:24 UTC ---
(In reply to comment #19)
> (In reply to comment #15)
> 
> I find the short form sendMessage API to be no simpler than the array version
> since the burden of having to refer to the MIDI protocol spec to find out how
> to construct the data bytes remains. I agree with Jussi that programmers will
> therefore write sendNoteOn kind of wrappers to even the shorter sendMessage API
> .. due to this remaining conceptual burden.
> 
> So, if the byte protocol is going to be exposed to API users without support
> for constructing the bytes, then having a single array based sendMIDIMessage
> (or simply send()) is strictly simpler. It may also help set expectations that
> no message verification will be performed by the API.

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.

> If easing a developer's conceptual burden in the API is important, then it will
> be conceptually simpler to have multiple functions that hide the byte protocol
> - like sendNoteOn(timestamp, channel, pitch, velocity), perhaps with velocity
> in [0,1] range even. Covering the most common cases of noteOn, noteOff and
> controller change and allNotesOff may be enough.

Yes, but I'm not quite convinced that even that is necessary. The source of the
message may well not be the part of the program that actually sends the
message, for example in a sequencer where there's a predefined track of events.
The problem with trying to cater ease of use to the common case with MIDI is
that there is no such thing, different programs require different approaches.

> If developers are to write their own wrappers, performance isn't an issue (I
> think). I found that a sendNoteOn wrapper on top of a shared Uint8Array based
> implementation gave me more than 10 million overhead calls per second on my
> macbook air (https://gist.github.com/3652045). That's 50x the capacity needed
> to send 100Hz control messages to each of 128 controllers in each of 16
> channels through individual function calls.

My point exactly. Even mobile devices have to be seriously on the edge of their
performance already if communicating with MIDI is going to be a problem.

> Regarding naming, the array in MIDIMessage can hold more than one message, but
> the name suggests that it holds only one. Maybe adopt the CoreMIDI name
> "MIDIPacket" instead? A shorter send() function name also seems more correct
> for this reason.

Good idea!

-- 
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:12:26 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 9 September 2012 08:12:29 GMT