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

On 17 Dec 2012, at 19:12, Chris Wilson <cwilso@google.com> wrote:

> Actually, the main reason that I finally talked myself into the array was that it does not work well to have 
> 
> send( data0, data1, data2, timestamp)
> 
> because many MIDI messages are one or two bytes, not three.

Yeah, makes sense.

>  You need the number of data parameters to be variable, but also the timestamp to be optional (I feel very strongly about this).
> 
> Not sure why this was a surprise - we talked about it at great length in the bug and in email.  Perhaps surprise that I caved.  :)  But seriously, that's why I wrote the polyfill - because it let me test out the API in practice.  I couldn't come up with anything that was easier to use.
> 
> If we were to consider changing this to overload it, I'd suggest 
> 
> void send ( sequence<short> data, optional DOMHighResTimeStamp? timestamp );
> void send ( short status, optional short data1, optional short data2 );

This reminds me: why "short" instead of "byte" as the type? I raised that in another email as it applies generally.

> 
> that is, omitting the timestamp altogether in the separate data byte version (that's what we had before).  I didn't (and don't) see any other way to make the overload work, without making timestamp non-optional and moving it the front (which I am very against) or making it only work with 3-byte messages (which I think is a bad option also, as it will make it confusingly hard, for example, to send program change messages or system real-time messages).

Agree. Could get pretty ugly. I think we should make sure examples in the spec always use the pattern Jussi mentioned:

var data = [...]
output.send(data);



> 
> 
> 
> On Mon, Dec 17, 2012 at 6:43 AM, Marcos Caceres <marcosscaceres@gmail.com> wrote:
>> 
>> 
>> On Monday, December 17, 2012 at 4:35 PM, Jussi Kalliokoski wrote:
>> 
>> > Sure!
>> >
>> > output.send(90, 60, 122, 100) // wat! looks like a part of the data?!
>> >
>> > output.send([90, 60, 122], 100) // now the data is separate from the timestamp
>> >
>> > My point is that if you think about the action the send() has, it sends some data at a specified time; that's two arguments, data and timestamp. You can go arbitrarily splitting that into more arguments, but what's the point?
>> Sold:) Thanks Jussi, that makes sense now.
>