[Bug 18764] MIDI messages don't all have a channel, and status should be part of data.

https://www.w3.org/Bugs/Public/show_bug.cgi?id=18764

--- Comment #33 from Jussi Kalliokoski <jussi.kalliokoski@gmail.com> 2012-09-11 10:15:47 UTC ---
(In reply to comment #28)
>  (In reply to comment #26)
> > > 1) I disagree that it's not worthwhile to add a simpler API to skip six lines
> > > of code in a very common use case,
> > 
> > I've yet to see a demonstration that this is a more common case than any other.
> 
> How can I demonstrate evidence that sending MIDI note on/off/CC/realtime
> messages is more common than sending sysex?  Obviously, pointers to my Github
> projects would seem biased.  :)
> 
> I know that a large part of my motivation in sparking getting a Web MIDI API
> off the ground was wanting to tie real-world controllers to the Web Audio API;
> as I have a pile of MIDI synths (and mixers, effect units, etc) in my studio,
> obviously I'd like web sequencing to work well, too, but of course everyone has
> their biases.  I think we should be optimizing (not SOLELY optimizing, but
> optimizing) around the use case of developers wanting to enable controllers
> (not just controllerist, but keyboards, drum pads, mixers, lighting, guitar
> controllers, etc as well) - and I do think that case heavily uses short
> messages (as they construct the messages on the fly most of the time, rather
> than having pre-recorded sequences of data.)

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?

-- 
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 10:15:53 UTC