Re: MIDI Tracks and Sequences

On Sun, Sep 16, 2012 at 10:06 AM, James Ingram <j.ingram@netcologne.de>wrote:

> https://gist.github.com/**3728539 <https://gist.github.com/3728539>:
> On my machine, the schedule deviation gradually increases (irregularly),
> and I noticed that it was getting increasingly erratic after about 160000
> ms (2min 40sec), so decided to let it run longer to see what happened. I've
> now doubled the length of the sequence (see test 7 [1]). If you don't hit
> the stop button, the test will now run just short of 350000ms (5min 50sec).
> After about 240000ms a pattern emerges. I don't know what the pattern
> means, but have added a "devDelta" field to the log showing the difference
> between successive deviations, so that you can see it more clearly. The
> "deviation" field is the "sequence deviation" field, as before.
> The sequence itself contains a repeating 4-duration cycle of 50, 50, 50,
> 200ms, and by the end of the performance the scheduling deviations have
> also settled down into a 4-value cycle: 350, 300, 250, 200 or 351, 301,
> 251, 201 or similar. The 50ms differences seem quite constant, but the
> deviations are still gradually increasing as a whole.
>

Hmm.  1) I suppose I could have said

        window.setTimeout(tick, delay-5);  // this will schedule the next tick.

So that the timeout fires before the note is supposed to be sent (5 being
an arbitrary number).  But seriously, without the timeouts being
implemented, this is going to have some slop.

2) Jazz only currently loads on ONE of my systems - all others give "Could
not load Jazz plugin."  I believe it's only working on Chrome 21 and
previous.  I'm talking to Sema, the author of Jazz, directly about this
issue, but don't be surprised when it stops working.  :(

3) I saw this behavior (wildly increasing delays) and then didn't see it
again.  It SEEMED like it was an artifact of the setTimeout not getting
called back for upwards of a second, which of course was QUITE wrong; I
expect the problem was that the send()s were taking so long, the time got
out of date by the end of the loop.  Should probably update
domhrtRelativeTime and delay inside the loop.  This problem, too, should go
away with a proper implementation.


> And there's another thing that I still don't quite get.
> If the system is supposed to send the message at its timestamp time, how
> does it know when the performance started?


You told it, when you assigned domhrtTimeAtStartOfPerformance =
window.performance.webkitNow();

I suspect that there is an error in test 7 (left over from my previous
> tests) , and that the timestamp sent to the system should actually be
> simple DOMHRT time (relative to session start), rather than
> performance-relative time. Is that right?
>

Hmm, yes, when delays are implemented you should be setting the
msg.timestamp in each message to += domhrtTimeAtStartOfPerformance.


> This would not make any difference to the other code in test 7, but it
> sure would to the time at which the system is supposed to send the message.
> If I'm right, then all the timestamps in test 7 would be in the past as
> far as the system is concerned. So the system would be sending the messages
> immediately (which is what we are expecting anyway with PREQUEUE=0). This
> error (if it is one) is only going to show up when the value of PREQUEUE is
> increased, and we start trying to schedule messages in the future.


Yes.


>  Things like this is why we need native implementations of the MIDI API.
>>
> Any chance of that happening in the near future?
>

Well, obviously that's why I'm pushing this API along.  But I don't have
any announcement there; still looking for a webkit implementer.

-Chris