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

Re: Timing limitations when programming MIDI with Javascript

From: Marcus Geelnard <mage@opera.com>
Date: Tue, 05 Jun 2012 09:08:42 +0200
To: "Jussi Kalliokoski" <jussi.kalliokoski@gmail.com>, "Chris Wilson" <cwilso@google.com>
Cc: "James Ingram" <j.ingram@netcologne.de>, public-audio@w3.org
Message-ID: <op.wfe4ssf4m77heq@mage-desktop>
Den 2012-06-04 20:14:14 skrev Chris Wilson <cwilso@google.com>:

> Was just about to hit send on a reply to James when Jussi's mail came in.
>  +1 to what he said.
>
> The only thing I'd add is the the current spec treats DOMHighResTimeStamp
> as if it has an innate zero-reference point (a la "milliseconds since  
> UNIX
> epoch"), which it does not - unless we explicitly refer to
> window.performance.now().
>
> Also, in noting that the params are readonly, I'm starting to wonder if  
> it
> would be best to stay with this API but additionally have a "send short
> message immediately" that doesn't use the MIDIMessage structure - it  
> seems
> like overkill to create a UInt8Array, call createMIDIMessage, etc.  when
> what I really want to do is
>
> out.sendShortMessage( out.NOTEON, channel, notenumber, velocity );
>
> Definition would look something like
>
> boolean  createMIDIMessage (short status, short channel, short? data1,
> short? data2);

Just a quick thought here... I have only had a quick look at the Web MIDI  
API specification, and I must admit I'm no MIDI expert (which is why I  
haven't provided any feedback so far). However, I think that one of the  
neat things about the spec, as it is today, is that it does not seem to  
limit itself to a specific version of the MIDI specification (somewhere  
around [1] ?).

I think that we should be very careful if we want to provide shorthand  
methods for constructing/parsing messages, since that would make the Web  
MIDI API dependent upon another specification (right?), and probably even  
a specific version of another specification.

By all means, if the shorthand/convenience functions can actually improve  
performance somehow (less GC, lower latency etc), it might be worth  
considering including them in the spec. Otherwise I don't see why  
shorthand methods can't be provided by a JS lib that can adopt new MIDI  
versions much quicker than a Web standard, for instance.


[1] http://www.midi.org/techspecs/index.php


/Marcus
Received on Tuesday, 5 June 2012 07:08:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 5 June 2012 07:08:58 GMT