W3C home > Mailing lists > Public > public-audio-dev@w3.org > March 2013

Re: Assistant Performer

From: Chris Wilson <cwilso@google.com>
Date: Wed, 6 Mar 2013 16:33:17 -0800
Message-ID: <CAJK2wqWVpZid_wvZunGuSE4o6aOGMYtzGTOSdL451zR+XNDaNg@mail.gmail.com>
To: James Ingram <j.ingram@netcologne.de>
Cc: public-audio-dev@w3.org
On Wed, Mar 6, 2013 at 11:02 AM, James Ingram <j.ingram@netcologne.de>wrote:

> While writing this code, I made the following notes. Are either of these
> "issues" which should be raised on [4]?
> 1. Should/Do Ports support opening and closing? (I think Jazz 1.2 is doing
> this automatically). I'm afraid I don't understand how this is supposed to
> work in the Web MIDI API.

Not directly, no - ports "open" when they are obtained (from
getInput/getOutput), and close when they are released.

2. The current spec says (section 7.3.1):
>    "Running status is not allowed in the data, as underlying systems may
> not support it."
> But some systems MAY support it, so why do we have to rule it out? Do some
> MIDI devices fail to ignore these events if they can't understand them?

Any MIDI device that sends running status to a MIDI interface will have it
converted to standard messages before it gets into the OS MIDI support
anyway (and USB-MIDI does not support it).  What this does, is prevent
SENDING of running status messages through the send() method - because
otherwise, the Web MIDI implementation would be forced to unroll the
running status anyway (to check its validity, and to send to USB-MIDI
devices).  Note that this is not unique - CoreMIDI, for example, explicitly
disallows running status in a MIDIPacket's data.  (See comment in the data
parameter of

This does not prevent you using a MIDI device, connected through a 5-pin
DIN connector, that sends running status - that running status just gets
converted in the chain before it gets to the Windows/Mac API, or before it
hits USB if you're using a USB-MIDI interface.  The only thing this
prevents you doing, pragmatically, is ramming data containing running
status into a send()'s buffer parameter - and we don't really need message
compression in that method, in my opinion, particularly as we'll have to
expand in to test validity (and to pass on to CoreMIDI, at least) anyway.

Received on Thursday, 7 March 2013 00:33:45 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:43:28 UTC