Re: Timing limitations when programming MIDI with Javascript

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

best,
James

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