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 07:20:55 +0000
Message-Id: <E1TBhFn-0006wd-NO@jessica.w3.org>
To: public-audio@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18764

--- Comment #36 from Jussi Kalliokoski <jussi.kalliokoski@gmail.com> 2012-09-12 07:20:52 UTC ---
(In reply to comment #34)
> (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.

Of course, use the right tool for the job. But programming is all about
abstraction. You have something and change the abstraction into something else,
but in the end it's all just data. Keeping programmers from having to do
abstraction in a low-level API is counter-productive.

> Plus you're suggesting wrapping ANOTHER layer around what I'm already saying I
> think is too many layers.  :)

Yep, but I'm suggesting the extra layers stay on the user side rather than the
API side.

document.createElement('div') might be the most used case of creating a DOM
element, but even though it saves a few characters, it really doesn't make
sense to add a window.createDiv() method. If we start adding methods for saving
a few characters we're going to end up with a framework instead of an API, and
web frameworks should stay in the user-world side.

-- 
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 07:20:56 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 12 September 2012 07:20:57 GMT