Re: [Web MIDI API] send() method should also allow 3 shorts + timestamp

The main reason send( status, data1, data2 ) didn't make it in was simply
that I didn't see a strong enough need (over send( [ status, data1, data2
], optional timestamp )).  If more than one person thinks its valuable, I'm
happy to add it.


On Sun, Dec 23, 2012 at 11:44 AM, Marcos Caceres
<marcosscaceres@gmail.com>wrote:

>
> Hi Florian,
>
> On Sunday, 16 December 2012 at 22:55, Florian Bomers wrote:
>
> > Hi Marcos,
> >
> > IMO, a separate method for sending 3-byte MIDI messages does not
> > really hurt (although it might even /cause/ confusion -- sometimes you
> > need brackets, sometimes not...).
> >
>
> Maybe, but web developers are well accustomed with working with overloaded
> methods. For example, jQuery's $( ) is overloaded to fire onload, run a CSS
> selector, create a set of nodes from a given input, and probably quite a
> few other things.
> > But it's just a wrapper method and
> > can be implemented easily in an own method, or in a library. And
> > chances are that you'll use more specific wrappers in your code
> > anyway.
> >
>
> This is true. However, we should still aim to make the API as developer
> friendly as possible, so that they don't need to rely on libraries (as this
> ends up causing it's own set of issues).
> > Example:
> >
> > void sendController(short ctrl, double normalizedValue /* 0...1 */)
> > {
> > ctrlMIDIDevice.send([0xB0 | ctrlChannel, ctrl,
> > normalizedValue * 127]);
> > }
> >
> > (where ctrlMIDIDevice and ctrlChannel are declared elsewhere).
> >
> > I guess you know that there are valid MIDI messages of any length.
> Yes, absolutely. But the most common case is to send a message of 3 bytes,
> no? I see Chris argued heavily for that also in the bug you pointed to.
> > Personally, I'm very happy that the current webmidi API does not favor
> > any particular length of MIDI messages (as many other MIDI API's do).
> > Here, there is a good opportunity to encourage also advanced use of
> > MIDI with Sys Ex, Show Control, etc.
> >
>
> Agree. My motivation is to give flexibility on both.
> > For a long discussion of different flavors of the send method(s) --
> > only for the very curious, I guess:
> > <https://www.w3.org/Bugs/Public/show_bug.cgi?id=18764>
> >
>
> Thanks for the pointer! This was really helpful. However, it was not
> entirely clear from reading the thread why send(byte byte1, optional byte
> byte2, optional byte3) was not also added to the API. I thought Chris made
> a strong case for it, and it's the same argument I'm trying to make.
>
>
>
>