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, 12 Sep 2012 06:03:22 +0000
Message-Id: <E1TBg2k-0002Zx-MS@jessica.w3.org>
To: public-audio@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18764

--- Comment #35 from Srikumar Subramanian (Kumar) <srikumarks@gmail.com> 2012-09-12 06:03:22 UTC ---
(In reply to comment #34)

Taking a look at Chris Wilson's github repo, the 3 byte sendMessage call has
been used quite a bit to turn on/off lights/buttons on a controller.  For these
cases, clearly sendMessage is the right level of abstraction and names such as
noteOn/noteOff/controllerChange are not. Indeed, even the MIDI spec for noteOn
as [0x90 + channel, noteNumber, velocity] is useless, since the byte values are
used for entirely different purposes such as setting the colour of a button.

For those interested in making noises via a softsynth available on standard
computers however, noteOn()/noteOff()/etc. are the right level of abstraction
since it saves developers who may not be intimate with MIDI the trouble of
referring to the MIDI spec first.

For the controller display cases, if you consider someone fresh to a controller
who needs to lookup its manual to find out what MIDI messages to send to it,
will the manual entry for a light on message be found to be worded as, say,
"send a noteOn message giving the button number in the pitch field and the
brightness level as velocity" or as "send a three byte message [0x90,
buttonNumber, brightness]". If the former, then a noteOn-like API still makes
sense. If the latter, then a raw 3-byte form makes sense. If both are used,
then it may benefit developers to have both kinds of APIs.

So it looks to me like this debate boils down to whether the WG is to implement
a MIDI API for its sound making aspects or for the general uses its protocol
can be put to. 

> (In reply to comment #33)
> > Hmm, do you think these use cases, where - as you said - the developers have a
> > hard time wrapping their head around the conceptual overhead of
> > port.send({data: Uint8Array([...])}), are better served by the short message
> > pattern rather than a small library that provides them with methods like
> > noteOn(), controllerChange() etc. and abstracts the send() interface away for
> > them?
> 
> Yes, because most of those noteOn()/controller() calls have higher-level
> semantics.  I would wrap a scenario-specific library with "turnOnLights()"
> calls or something, and those would have implementations that translate into 3
> bytes of data.  We shouldn't need to have app libraries just to hide the
> details of the funky boilerplate, and I don't think in general the note on
> message vs controller semantic is a necessary one; you use what you need at
> that point in your app.  In some cases, you'll be writing a learning/remapping
> layer anyway, that might need to change what calls you're making.
> 
> Plus you're suggesting wrapping ANOTHER layer around what I'm already saying I
> think is too many layers.  :)

-- 
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, 12 September 2012 06:03:24 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 12 September 2012 06:03:26 GMT