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

Re: Timing limitations when programming MIDI with Javascript

From: Chris Wilson <cwilso@google.com>
Date: Tue, 5 Jun 2012 13:03:14 -0700
Message-ID: <CAJK2wqX-+2n1n8_L3d=FqOYzUsWSSnksA+4ezTLBOyL2YNzKvw@mail.gmail.com>
To: Jussi Kalliokoski <jussi.kalliokoski@gmail.com>
Cc: James Ingram <j.ingram@netcologne.de>, public-audio@w3.org
yeesh, right you are - the example I was looking at didn't use them, but
they are there, and they're passed into the Java object.  No idea if it
actually uses them.

On Tue, Jun 5, 2012 at 12:43 PM, Jussi Kalliokoski <
jussi.kalliokoski@gmail.com> wrote:

> On Tue, Jun 5, 2012 at 10:26 PM, James Ingram <j.ingram@netcologne.de>wrote:
>> 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...
> Looking at the code, it looks like MIDIBridge has timestamps, but I'm not
> sure if they affect anything, gotta try later.
> Cheers,
> Jussi
Received on Tuesday, 5 June 2012 20:03:48 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:03:04 UTC