20510 2012-12-24 08:23:52 +0000 send(sequence<short> data) should just be send(any data) 2013-01-18 15:50:53 +0000 1 1 1 Unclassified AudioWG MIDI API unspecified PC All CLOSED FIXED P2 normal TBD 1 w3c cwilso cwilso jussi.kalliokoski w3c public-audio oldest_to_newest 80557 0 w3c 2012-12-24 08:23:52 +0000 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… 80574 1 jussi.kalliokoski 2012-12-25 23:18:35 +0000 (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] 80576 2 cwilso 2012-12-25 23:23:40 +0000 (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? 80577 3 jussi.kalliokoski 2012-12-25 23:29:47 +0000 (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. 80580 4 w3c 2012-12-25 23:49:57 +0000 (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? 80581 5 jussi.kalliokoski 2012-12-26 00:07:39 +0000 (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. 80595 6 cwilso 2012-12-26 17:18:40 +0000 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?" 80598 7 w3c 2012-12-26 17:38:10 +0000 (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 80599 8 w3c 2012-12-26 17:39:30 +0000 (In reply to comment #7) > (In reply to comment #6) > No, you just get an array with 240 zeros in it :) err, 248. Anyways :) 80600 9 cwilso 2012-12-26 17:46:42 +0000 That sounds more directive to me. :) 80601 10 w3c 2012-12-26 17:58:11 +0000 (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). 80608 11 cwilso 2012-12-26 18:44:30 +0000 (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. 80609 12 cwilso 2012-12-26 18:48:53 +0000 https://github.com/WebAudio/web-midi-api/commit/827afb647d68ea2007dcf78946ec9d8a90f84f9a 81565 13 olivier.thereaux 2013-01-18 15:50:53 +0000 Batch-closing RESOLVED MIDI issues. Reminder: midi issues now tracked at https://github.com/WebAudio/web-midi-api/issues