I'm encountering a strange issue with transport when looped using the timepoint object. I have found a number of other references to timepoint/transport issues in the forums, but this one is perplexing because the metro that is sync'd to the transport appears to get pushed out of sync by a specific amount each time the transport loops.

The following code example makes this problem audible. A quarter-note pulse is triggered directly by the transport, and another quarter-note pulse a fifth higher is triggered from the synchronized metronome. After the timepoint object causes the transport to loop, the higher tone goes out of synch by a 16th note (either pushed three forward or one back). the metro also sends out a double bang when timepoint loops, as you can see by the timer output of 0.000 every time timepoint loops the transport. I've been able to filter out the double bang using a speedlim object, but it doesn't solve the desynchronizing issue.

I don't know if this is a bug or an issue in my coding, but any help or insight would be greatly appreciated. Many thanks!

I'm encountering a strange issue with transport when looped using the timepoint object. I have found a number of other references to timepoint/transport issues in the forums, but this one is perplexing because the metro that is sync'd to the transport appears to get pushed out of sync by a specific amount each time the transport loops. 

strange-behavior-with-transport-based-looping

Try resetting the counter below Metro 1 to 0 (instead of 3).

The counter, if you watch it, loops many times for each bar before the timepoint object loops the transport, so I'm not sure how what number I reset it to causes everything to shift off a 16th. The reset to 3 only happens when you initialize the patch or stop/start the toggle, and it is done so that the first note out of the itable is from X=0.

I slowed down the tempo to 20 or so and watched what happened to the counter when the timepoint loops, and it suddenly skips a value, like going from 0 to 2 over one metro beat. The only explanation I have for that (which the Max Window appears to show), is that the metro sends out a double bang when the transport loop happens. I've put a speedlim object between the metro and the counter, but even a speedlim time of 80ms does not remove the problem. So I guess the question is, how to remove that double bang, or just turn it into a single bang without inadvertently removing other metro beats.

The counter, if you watch it, loops many times for each bar before the timepoint object loops the transport, so I'm not sure how what number I reset it to causes everything to shift off a 16th. The reset to 3 only happens when you initialize the patch or stop/start the toggle, and it is done so that the first note out of the itable is from X=0. 

I slowed down the tempo to 20 or so and watched what happened to the counter when the timepoint loops, and it suddenly skips a value, like going from 0 to 2 over one metro beat. The only explanation I have for that (which the Max Window appears to show), is that the metro sends out a double bang when the transport loop happens. I've put a speedlim object between the metro and the counter, but even a speedlim time of 80ms does not remove the problem. So I guess the question is, how to remove that double bang, or just turn it into a single bang without inadvertently removing other metro beats. 

Strange Behavior with Transport-based Looping