Re: MIDI Tracks and Sequences

Doh! But that's fantastic! I am very excited that this is now working. 
Bravo Chris! Bravo Jazz too!

For completeness, I've uploaded Test 11 [1] in which I've used 
console.log everywhere except in the introduction.
I've run this test twice: Its completely stable, and I get a maximum 
difference of 2ms (!) between the timestamp and the DOMHRT time.

I'm expecting sequences to contain very short durations between 
sendMIDIMessages. Even in quite conservative music, this is something 
one has to expect - especially when sending parallel tracks containing 
lots of controller data.
So I made a really hard stress-test to see what would happen. I wanted 
to see if I could crash it.
Test 12 [2] sends 160000 note-ons at the rate of 1ms per note-on. Thats 
160 sec = 2min 40sec.
It does not crash. When run on my system, the difference between the 
timestamps and DOMHRT time settled down to  rotating ca 7, 6, 5, 4, 3, 
2, 1ms, so that packets of 7 messages seem to be being sent at the same 
time. Maximum deviation was reported  (on completion) as 98ms, so there 
must have been a little glitch somewhere...
Maybe, when sendMIDIMessages is conformant, and PREQUEUE is increased, 
this behaviour may improve because we wont be calling setTimeout so often.

I'm currently writing Sequence, Track and MIDIMoment objects as part of 
my current project, and will be including a version of the test 11-12 
code in the Sequence.play() functions. No deadlines, but I'll let you 
know when its working.

All the best, and thank you Chris for your patience and help!
WOW!
James

p.s. Does anyone know if the MIDI standard says anything about how long 
it should take for a program change message to take effect?

[1] http://james-ingram.de/tests/JazzMIDIBridge/ji-known-sequence11.html
[2] http://james-ingram.de/tests/JazzMIDIBridge/ji-known-sequence12.html



Am 18.09.2012 19:13, schrieb Chris Wilson:
> Heh.
>
> What appears to be degrading over time is your logging code.  I 
> switched to console.log, and it stays rock-solid, within 4ms max 
> variance.  Not too surprising, I suppose, since by the end of the loop 
> you have a 4000-line-tall chunk, and every time you're doing an 
> innerHTML+= and a scroll.  That's ending up as a large 
> reparse/relayout cost.
>
> On Tue, Sep 18, 2012 at 1:39 AM, James Ingram <j.ingram@netcologne.de 
> <mailto:j.ingram@netcologne.de>> wrote:
>
>     Sorry, I forgot to include the links to the last two tests.
>
>     Test 9:
>     http://james-ingram.de/tests/JazzMIDIBridge/ji-known-sequence9.html
>
>     Test 10:
>     http://james-ingram.de/tests/JazzMIDIBridge/ji-known-sequence10.html
>
>     best,
>     James
>
>


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

Received on Tuesday, 18 September 2012 21:58:18 UTC