After init/start of the timer, this example will play segment 0 and then enter segment1 where it loops …
if you monitor the textport, you will see that by the time “onSegmentEnter” is called, the timer_fraction is always correctly at 0.0
But if you (like in text4 script) use goTo() to activate a different segment, then:
you will see that by the time “onSegmentEnter” is called, the timer_fraction is still at the fraction it was when goTo() was called. timerIssue.tox (1.14 KB)
part 3: this example is supposed to jump to segment 0 if segment 1 exits. So in onSegmentExit()
if segment == 1:
op("timer2").goTo(segment = 0, endOfCycle=False)
but this will enter segment 2 and then immediately go to segment 0 . I would expect that in this case I would directly go to segment 0 timerIssue3.tox (1.28 KB)
I’ve fixed the first issue, to better handle goTo’s during enter/exitSegment,
but as for Issue #1:
The channels are updated, then callbacks executed.
Your callback changes the timer state again, so the channels will be updated on the next cook.
By accessing its own channels during the cook, you’ll run into these problems.
I’ve added an op(‘timer1’).fraction method that returns the current fraction value.
This is safe during callbacks which change the state of the timer mid-cook.
Similarly, for Issue #2,
The Info DAT cooks outside of the Timer CHOP, so accessing it during Timer callbacks may give undetermined results.
It’s safe to access the Timer CHOPs state directly, inside its own callback: print(op(‘table1’)[ timerOp.segment+1, ‘test’] )
vs print(op(‘info1’)[‘test’,1])
Or we could add a similar op(‘timer1’).infoColumn(‘test’) function for example.