[seq] (start -1) costs 20ms on each loop

[styk-tv]

To define the problem correctly, let me start with the definition from the documentation on [seq] (start-1)

After careful examination of the data produced by [seq] when used in loop mode, I have noticed a 20ms delay (on my machine) when starting the pattern in a loop mode. This occurs only in self-synchronisation mode "start -1" which would be a preferred method as allows precise control of tempo outside of midi file.

Starting sequence using "start 1024" loops with no issue, however provides no control over initial tempo which in this case is inherited from midi file directly and cannot be easily inspected for recalculation if required.

Debugging messages show exactly sequence restart and duration of each eight note. You can clearly see that delay of 20ms presents during startup when using "step -1". During single midi file playback you wouldn't notice this really, however when engaging midi tracks in loop mode this becomes audible and over larger durations introduces cumulative time shift in performance.

Any tricks on how to avoid using subsequent track restarts "start -1" and maybe employ a different less expensive means of looping based on position shift? Or perhaps using internal clock but with ability to overwrite tempo of a file loaded into seq?

Midi file used:

0, 0, Header, 0, 1, 96
1, 0, Start_track
1, 0, Title_t, "\000"
1, 0, Time_signature, 4, 2, 36, 8
1, 0, Time_signature, 4, 2, 36, 8
1, 0, Note_on_c, 0, 60, 100
1, 48, Note_off_c, 0, 60, 64
1, 96, Note_on_c, 0, 67, 100
1, 144, Note_off_c, 0, 67, 64
1, 192, Note_on_c, 0, 64, 100
1, 240, Note_off_c, 0, 64, 64
1, 288, Note_on_c, 0, 62, 100
1, 336, Note_off_c, 0, 62, 64
1, 384, End_track
0, 0, End_of_file

one-bar-4x-8th-notes.384.mid.zip

[porres]

After careful examination of the data produced by [seq] when used in loop mode

what is the "loop mode"?

this delay seems to be the delay from the [metro].

anyway, this is what you gotta do when you post an issue, please give us a very very simple and minimal patch that we can use to see if we can reproduce the issue. thanks

[styk-tv]

hello @porres [seq] (start -1) is expensive. on my system at least 20ms no matter how I try this. I hope I'm wrong and this is just a small bug in my patch. i would appreciate confirmation. note.in is from else. any hints as to lossless rewind would be much much appreciated.

seq-restart-expensive-20ms.pd.zip

[porres]

have you tried the fix?

[styk-tv]

Yes fix for the end-of-track (as per confirmation in https://github.com/porres/pd-cyclone/issues/561 works perfectly, it fixes the end of track issue, this delay is caused by rewind (last to first) and happens between last and first tick. Essentially here, the (start-1 initialization - since cheap rewind does not exist) rewind from last to first somehow does or cannot adhere to the ticking convention. Would anyone be able to confirm RCA for this?

This example works fine with internal clock (when set to 1024 - "play with midi tempo"), however [seq] object does not externalize essential midi details like internal initial tempo (ppq would also be nice) and without this information not easily possible to determine what "midi tempo" was used hence external formula for tempo change is missing a starting point for tempo adjustment calculations.

[porres]

I meant the fix for this, not end of track. This issue has already been closed and fixed

[styk-tv]

no, i just noticed ticket close is linked to a commit, verifying now. will attach result here. thank you.

[porres]

i just noticed ticket close is linked to a commit

this means that the commit fixes the problem