W3C home > Mailing lists > Public > public-audio@w3.org > April to June 2012

Comments on draft MIDI API

From: Dominique Hazael-Massieux <dom@w3.org>
Date: Tue, 26 Jun 2012 15:23:46 +0200
Message-ID: <1340717026.3217.761.camel@altostratustier>
To: public-audio@w3.org

As I'm glancing through the editors of the proposed MIDI API [1], a few
comments on problems I've spotted:

* sequence<> shouldn't be used as attributes (but instead arrays should
be used) in MIDIEvent

* prefixing all properties in MIDIDevice with "device" seems a bit

* MIDIDevice should have a type (or deviceType) attribute instead of
defining it in MIDIInputDevice and MIDIOutputDevice; that type attribute
should be defined with an enum with values "INPUT" and "OUTPUT" (not
sure why it needs uppercase though)

* I'm surprised that the enumerate*/get* methods on MIDIAccess seem seem
to synchronous; I would expect that these operations would require
enough time that they shouldn't block the main thread; also, it doesn't
look like the API allows to deal with plugging/unplugging MIDI devices

* if getInput/getOutput can also take a string parameter (for the
fingerprint), the type of the parameter should be (MIDIDevice or

* Uint8Array is not defined in WebIDL; I guess it comes from WebGL, but
then that spec should probably be referred

* NavigatorMIDIAccessError should probably be removed in favor of a
DOMError with type SECURITY_ERROR (?)

* MIDIMessage should probably be a dictionary rather than an interface

At a higher level, it seems like this API has a very strong
fingerprinting risk (due to enumeration of devices, esp. as they
themselves have a fingerprint property). 

Also, I idly wonder if getting input from MIDI devices shouldn't be done
via getUserMedia rather than through its own API; I'm not really sure
how that would work, but I thought I would still share the question.


Received on Tuesday, 26 June 2012 13:24:15 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:03:05 UTC