(In reply to comment #0)
> If the first argument of send() is going to be coerced in to a Uint8Array,
> then send should just take any as a type. That avoids a whole bunch of
> unnecessary checks that will be performed when whatever value if thrown into
> new Uint8Array().
> 
> For example:
> 
> send({}) === []
> send(function(){}) === []
> send(Node) === []
> 
> send("") === [0]
> send([" "]) === []
> 
> send([undefined,null,Node,Array, [1,23,432]]) === [0, 0, 0, 0, 0]
> 
> This one is important:
> send(["100", "200", "300"]) === [100, 200, 44]
> 
> 
> And so on…

Sounds good to me, but I have to point out that this will make it impossible to overload send():

send(3) = [0,0,0]

(In reply to comment #1)
> Sounds good to me, but I have to point out that this will make it impossible
> to overload send():
> 
> send(3) = [0,0,0]

And doesn't cause problems with the optional timestamp at the end, also?

(In reply to comment #2)
> And doesn't cause problems with the optional timestamp at the end, also?

Unless I misunderstood something, no, this would just affect the first argument.

(In reply to comment #1)
> Sounds good to me, but I have to point out that this will make it impossible
> to overload send():
> 
> send(3) = [0,0,0]

True. And good point about it expanding out :/ I didn't think of that and I don't know if that is bad or not. 

I guess worst case you get people sending something like:

send(0x90); 

Will any hardware die if it gets a long string of 0s?

(In reply to comment #4) 
> Will any hardware die if it gets a long string of 0s?

I doubt it. IIRC by spec that would be an invalid message, and therefore probably won't even be sent to USB-MIDI devices. As for normal MIDI devices, unless buggy, I think the message would just be skipped if they adhere to the spec. That might be a different case if we allowed partial messages (you'd probably be going FUBAR anyway if you sent a new message in the middle of a partial message anyway), but we don't.

I still don't see why this is a benefit (allowing "any").  This seems like being overly permissive (no checks), but there's one narrow "magic correct" version (an array of something that's actually numbers) that will actually work.  The others are just degenerate non-functional oddities.

Also - then I presume

.send( 0xf8 )

would actually work.  (Sends a Timing Clock message "tick".)  that seems to me like it will continually re-open the question of "why doesn't send( 0x90, 0x40, 0x7f ) work again?"

(In reply to comment #6)
> I still don't see why this is a benefit (allowing "any").  This seems like
> being overly permissive (no checks), but there's one narrow "magic correct"
> version (an array of something that's actually numbers) that will actually
> work.  The others are just degenerate non-functional oddities.
> 
> Also - then I presume
> 
> .send( 0xf8 )
> 
> would actually work. 

No, you just get an array with 240 zeros in it :) 

> (Sends a Timing Clock message "tick".)  that seems to
> me like it will continually re-open the question of "why doesn't send( 0x90,
> 0x40, 0x7f ) work again?"

Ok, then lets just go with the sequence:

sequence<octet> data

And let WebIDL do its magic on each item of the array:
http://www.w3.org/TR/WebIDL/#es-octet

(In reply to comment #7)
> (In reply to comment #6)
> No, you just get an array with 240 zeros in it :) 

err, 248. Anyways :)

That sounds more directive to me.  :)

(In reply to comment #9)
> That sounds more directive to me.  :)

Ok, but the WebIDL bit is important here... in section 7.3.1 Methods, the spec has wording about how to send() messages that might conflict with WebIDL. 

For example:
"If data is not a valid sequence, does not contain a valid MIDI message, or if timestamp is passed but is not a valid DOMHighResTimeStamp, throw a TYPE_ERROR exception."

1. "valid MIDI message" is not defined, AFACT. 
2. and this is not needed, as it's handled by WebIDL: "if timestamp is passed but is not a valid DOMHighResTimeStamp, throw a TYPE_ERROR exception." 

(I think I already filed 2. above)

Also:
"The data MUST contain one or more valid, complete MIDI messages. Running status is not allowed in the data, as underlying systems may not support it."

1. Data is not a "conformance class", hence an RFC2119 keyword cannot be used there. Please change it to:

"The data contains one or more MIDI messages." 

The above is a statement of fact (which may or may not be true, but that is irrelevant until processed). 

2. It's unclear what "Running status is not allowed in the data" means. There is no algorithm defined in the specification to check for this (and do something if "running status" is found).

(In reply to comment #10)
> "If data is not a valid sequence, does not contain a valid MIDI message, or
> if timestamp is passed but is not a valid DOMHighResTimeStamp, throw a
> TYPE_ERROR exception."
> 
> 1. "valid MIDI message" is not defined, AFACT. 

Actually, it's defined by [[!MIDI]].  (Explicitly, as in there's a list of MIDI messages, + definition of sysex.)

> 2. and this is not needed, as it's handled by WebIDL: "if timestamp is
> passed but is not a valid DOMHighResTimeStamp, throw a TYPE_ERROR
> exception." 
> 
> (I think I already filed 2. above)

You did.  Already fixed.

> Also:
> "The data MUST contain one or more valid, complete MIDI messages. Running
> status is not allowed in the data, as underlying systems may not support it."
> 
> 1. Data is not a "conformance class", hence an RFC2119 keyword cannot be
> used there. Please change it to:
> 
> "The data contains one or more MIDI messages." 
> 
> The above is a statement of fact (which may or may not be true, but that is
> irrelevant until processed).

OK.
 
> 2. It's unclear what "Running status is not allowed in the data" means.
> There is no algorithm defined in the specification to check for this (and do
> something if "running status" is found).

Defined by [[!MIDI]] as well.  Online definitions of running status tend to be shaky; it is, in my opinion, a bit of a hack.  Or, more precisely - the format of MIDI messages is pretty well documented online (by http://www.midi.org/techspecs/midimessages.php, for example), but running status is not.  In short - if you process according to that link and fail if something looks like it's not a MIDI message, you are detecting and failing on running status.  Running status is additional compression layered on top.

https://github.com/WebAudio/web-midi-api/commit/827afb647d68ea2007dcf78946ec9d8a90f84f9a

Batch-closing RESOLVED MIDI issues. Reminder: midi issues now tracked at https://github.com/WebAudio/web-midi-api/issues