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: Tue, 11 Sep 2012 23:34:41 +0000
Message-Id: <E1TBZyb-0000Ky-2m@jessica.w3.org>
To: public-audio@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18764

--- Comment #34 from Chris Wilson <cwilso@gmail.com> 2012-09-11 23:34:37 UTC ---
(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 Tuesday, 11 September 2012 23:34:42 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 11 September 2012 23:34:42 GMT