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

Re: Timing limitations when programming MIDI with Javascript

From: Jussi Kalliokoski <jussi.kalliokoski@gmail.com>
Date: Mon, 4 Jun 2012 22:20:22 +0300
Message-ID: <CAJhzemWt1d50DuttwkrQ_SBEktwLkRE8mevQWoardFVM5z4-ZA@mail.gmail.com>
To: Chris Wilson <cwilso@google.com>
Cc: James Ingram <j.ingram@netcologne.de>, public-audio@w3.org
On Mon, Jun 4, 2012 at 9:14 PM, Chris Wilson <cwilso@google.com> wrote:

> 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().
>

I'll address this in the discussion about issue #105.


> 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);
>

I agree, the createMIDIMessage is awkward for most use cases right now, but
it was designed to address all the use cases. I originally had an overload
similar to this in mind, I just haven't added it yet because I'm not
completely sure what the form should be (as in what arguments it would
take). This looks like a pretty clean form, but I would add the optional
timestamp as a last argument.


> Additionally, I'm not sure why all the parameters in MIDIMessage are
> readonly?
>

 There's no good reason; to be honest, because I was too lazy to specify
what should happen if they're changed and to think about the possible
pitfalls. ;) This can be changed, I can fix that if we all agree and there
are no pitfalls, I see no reason not to.
Received on Monday, 4 June 2012 19:20:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 4 June 2012 19:20:56 GMT