Re: Timing limitations when programming MIDI with Javascript

On Tue, Jun 5, 2012 at 6:48 AM, James Ingram <j.ingram@netcologne.de> wrote:

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


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

-C