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

Re: Timing limitations when programming MIDI with Javascript

From: James Ingram <j.ingram@netcologne.de>
Date: Tue, 05 Jun 2012 21:26:39 +0200
Message-ID: <4FCE5D6F.7030307@netcologne.de>
To: Chris Wilson <cwilso@google.com>
CC: Jussi Kalliokoski <jussi.kalliokoski@gmail.com>, public-audio@w3.org
Hi Chris, all,

>         This is actually where the timestamps shine. You can have a
>         clock interval, like 200 milliseconds, where you proceed
>         reading a list of events and queue the events that are going
>         to occur in the following 200ms, and send them to be played at
>         respective times, without a need for individual setTimeouts
>         for each event which is very CPU-intensive, and not to mention
>         that events that are supposed to occur at the same time don't
>         necessarily do so, maybe due to GC or rendering or whatever is
>         blocking the next timeout.
>     I think the penny just dropped! Thanks for your patience. Is this
>     actually working in Midibridge? Perhaps there should be an example
>     in the docs...
> No.  MIDIBridge doesn't currently have timestamps, I don't believe.
So I'll have to go back to using setTimout() for the moment then (as I 
said, that's not the end of the world).
Is there any way that I could try using timestamps? That's going to have 
to be done sometime. The sooner the better...

>         35 seconds is quite a long time to read a score (our JS audio
>         codecs can read complete songs in a matter of seconds), I
>         suggest reading the score in a worker thread using a JS-based
>         DOM library to avoid the overhead that might come with browser
>         built-in DOM.
>     Am looking into this too, of course.
> +1 to what Jussi said.  35 seconds is far longer than I'd expect this 
> kind of code to take, even without a worker thread and JS-based DOM.
The point is well taken. As I said, I'm learning... :-)

Received on Tuesday, 5 June 2012 19:29:46 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:49:59 UTC