RESOLVED: Timer CHOP bug

win10, 2019.14650

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)

second issue:
this one prints the current segment “custom info DAT Column” in onSegmentEnter()

while the timer CHOP auto advances from segment 0 to segment 1

during onSegmentEnter() the info DAT still has the previous segments column value

if you use goTo next/prev segment buttons or the goTo() command, then

during onSegmentEnter() the info DAT has correct value
timerIssue.tox (1.2 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)

Thanks Achim, We’re having a look at these cases. greg

Hi Achim.

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.

Thoughts?

thank you. this was actually the main problem i had. The others just surfaced while searching for workarounds.

Does this actually refer to Issue #3? Cause in issue 1 there is no changing time state from the callback

While op(‘timer1’).infoColumn(‘test’) would be a nice and clean addition, I’m just as fine using op(‘table1’)[ timerOp.segment+1, ‘test’]

The main problem was that it behaved differently when auto-advancing vs when using goTo. If that (issue #1) is now fixed, I’m really fine with both

Sorry, I may have mixed up the labels:

Issue #1: I added member: .fraction, to use instead of reading its uncooked channels.

Issue #2: I suggest op(‘table1’)[ timerOp.segment+1, ‘test’], instead of reading a cook-dependent DAT.

Issue #3: Is now fixed. (goTo overriding during transitions)