Re: MIDI Tracks and Sequences

Chris,

Test 9 [1]
> In fact, I'd just track the time it's taking to call sendMIDIMessage() 
> first - I think that's what's causing the issue.
Test 9 Run three times. Interesting. I looked at this without rounding 
window.performance.webkitNow().
The result is that sendMIDIMessage() usually takes exactly 0ms, but half 
way through the runs (ca. 2000 sends) it suddenly, occasionally and 
irregularly starts taking a value very close to 1ms. These values are 
always either
1.0000000038417056ms
or
0.9999999965657480ms
Most of the time the durations are still 0ms though (until the end).
On the third run I noticed that the very first sendMIDIMessage also took
1.0000000038417056ms

Is that some kind of rounding bug in Jazz?
-------------------

Test 10 [2]
> I would suggest moving the updates of domhrtRelativeTime and delay 
> inside the loop, and log the webkitPerformanceNow time (and delay) 
> just before the call to setTimeout().

Test 10 [2]. Not sure if I understood what you were trying to do here. 
If I got it wrong, maybe you could upload the code as you did before.
I updated domhrtRelativeTime again before delay at the bottom of the 
loop, and logged domhrtRelativeTime and delay just before setTimeout.
Ran it twice: the delay value begins close below the note durations (as 
it should) but drifts slowly smaller. When the delays look as if they 
ought to go negative, everything starts getting erratic. At the end, the 
delay is alternating between 2 and 3 figure numbers.
--------------------

It might be worth mentioning that I'm sending the messages to the 
"Microsoft GS Wavetable Synth". Don't know if there's any handshaking 
going on down there.

best,
James



Am 17.09.2012 18:45, schrieb Chris Wilson:
> James,
>
> The deviations aren't really that disturbing; the disturbing part is 
> that from the timestamps, I'm guessing the actual sendMessage is 
> taking a long time.  As per last message, I would suggest moving the 
> updates of domhrtRelativeTime and delay inside the loop, and log the 
> webkitPerformanceNow time (and delay) just before the call to 
> setTimeout().  In fact, I'd just track the time it's taking to call 
> sendMIDIMessage() first - I think that's what's causing the issue. 
>  But I can't tell without seriously debugging, and as I mentioned, 
> Jazz isn't working for me anymore (at least, not on the machines I 
> have handy).
>
>
> On Mon, Sep 17, 2012 at 1:50 AM, James Ingram <j.ingram@netcologne.de 
> <mailto:j.ingram@netcologne.de>> wrote:
>
>     Hi Chris,
>
>
>     You said:
>
>          when delays are implemented you should be setting the
>         msg.timestamp in each message to +=
>         domhrtTimeAtStartOfPerformance.
>
>     immediately before the output.sendMIDIMessage(msg) call.
>
>     and -= domhrtTimeAtStartOfPerformance immediately afterwards
>     (before the msgIndex++), otherwise the sequence gets corrupted for
>     the next performance.
>
>     I've uploaded the correction as Test 8 [1] so that it doesn't get
>     lost.
>
>     I've run test 8 twice.
>     Run 1: crashed after about 2 minutes with a deviation of 1563ms (!).
>     Run 2: ran to completion (timestamp 349800), exhibiting the same
>     erratic behaviour as in test 7, and ending with the same repeating
>     pattern. The last 4 deviations were 305, 255, 205, 155. Maximum
>     deviation for the whole run was 313ms (at timestamp 345450).
>
>
>                 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.
>
>
>     Best of luck! :-)
>
>     greetings,
>     James
>
>     [1]
>     http://james-ingram.de/tests/JazzMIDIBridge/ji-known-sequence8.html
>
>     -- 
>     www.james-ingram-act-two.de <http://www.james-ingram-act-two.de>
>
>
>


-- 
www.james-ingram-act-two.de

Received on Monday, 17 September 2012 22:47:54 UTC