Noticing some unexpected behavior in the Timer CHOP (Build 2023.11880, Windows)
When using cycles, defined in either the Timer CHOP parameters or in an external Segments DAT, the output time measurements ‘cumulative_seconds’ and ‘master_seconds’ do not jump back on cycles. I also notice at the end of the final cycle, the value of ‘master_seconds’ will jump up during normal playback.
I’ve included a toe file with 3 examples showcasing this behavior.
TimerIssue_2023.11880.toe (9.8 KB)
Hi @mkhash,
both “cumulative seconds” and “master seconds” are described as:
It is a time count that adds up all the Timer Active times for all segments since Start
“master seconds” additionally also counts up when in a delay phase where “cumulative seconds” stops at that point. So that behavior is expected.
The jump at the end of “master seconds” I’ve logged as a bug.
Cheers
Markus
Hi @snaut,
Thanks for the explanation! I understand now how “master seconds” and “cumulative seconds” act during delay phases, but I am more confused about how they count during cycles.
I am basing my understanding of those values’ behavior based on this table in the timer CHOP documentation, which state that on cycle they should jump back.
As for “master seconds” specifically, I noticed in the 2022 build the value jumps back on cycle, whereas in the latest '23 build it does not.
2022.35320 example:
TimerMasterSeconds_2022.35320.toe (6.3 KB)
2023.11880 example:
TimerMasterSeconds_2023_11880.toe (6.2 KB)
1 Like
In you project, do you have a limit in the number of cycles? or do you exit the cycles using a end-cycle pulse?
Hi Mark, This is in the release notes for 2023:
Timer CHOP (https://docs.derivative.ca/Timer_CHOP) - Various improvements
- Next Segment / Prev Segment now updates
.masterSecondsproperly. - Stop resetting
.masterSecondseach cycle. - Fixed dropped pulse values.
From what I recall, we changed .masterSeconds for the case where it is deterministic, where you specify the number of cycles you want by using Cycle Limit. In this case, .masterSeconds continuously increases and ends up at the true number of seconds that has elapsed. In this case, if you do a goTo(time) or set .masterSeconds directly (same effect), it will put it at the correct time within the correct cycle.
In the case where you cycle and don’t turn on Cycle Limit, it is indeterminate when you goTo() or set .masterSeconds directly, so we have to make an assumption, using 1 cycle. In this way, a goTo() or setting .masterSeconds will go to a known place. To keep things consistent, we reset the masterSeconds after every cycle.
So the table you point out was not updated - it needs to spell out the two cases.
Yes there is a bug when driving it with a table, like where you have it set to 3 cycles. To calculate the masterSeconds after the cycles are complete, the Timer CHOP mistakenly uses the default value for number of cycles (4), instead of what you had i the table.
I think that’s how it is and the rationale. Given that, what behavior do you need? Perhaps by some logic in the callbacks.