Lets Talk: TimerCHOP

I am doing a little deeper dive in to timerCHOP, timecode and potential to drive content.

In General, Timecode is godsend and, for me, are the default now. But there are some things I would like to address with the timerCHOP in general.

Done

This is open for debate, but when is the timer DONE and when should we react to that?
Right now, the timerCHOP will reflect the doneState when it reaches the last frame. This means, that if we react to this to, for example, load a new movie or change a scene etc. we are in fact loosing one frame, as we do this action in the same frame as we reach that frame.
I would propose to move the onDone to one frame after the the last frame and add a new state/callback with onLastFrame/last_frame

Timecode/Frame - Length

This mainly seems to be an inconsistency between the newly timecode object and how frames/the timeline TD are handled.
The TimerCHOP is not starting at 0 with its frameIndex, but actually starts a 1. A 0 frameIndex is possible, but only signaling an inactive state for the timterCHOP. That is, tbh, extremly unfortanate. But ok, tis is the way it is right now and wont change as it is basicly baked in to the DNA of TD.
But, this right now results in wrong behaviour with Timecode.
Timecode starts at 00:00:00:00, which is reffering to the first frame. The timecodeCHOP refferencing a timerCHOP is showing the wrong behaviour though (I suppose because of the index 1 based indexing).
The timecodeCHOP will show the same/similiar behaviour and actualy and on the length number of frames, instead of -1.
Example: A timerCHOP with a length of 100 frames will end on 00:00:01:40 (at 60 fps). When we use this timecode to drive a movieFileInTOP we either get the first frame again, as we wrap arround, or we play the last frame twice. It should instead end on 00:00:01.39, as 00:00:00:00 is a valid frame in itself.

The length of 1 Frame

Right now, (at least in 11880), setting a timerCHOP to a length of 1 an starting it, results in the onDone callback being called instantly, in the same frame as it started.
I have to set the length to 2 frames to get the onDone callback in the next frame. This, again feels wrong, but circles back to the top question of when the timer is done. Is it done while is it basicly stlll running the last frame or 1 frame after that?

Running, index etc.

The whole timeline starting at 1 is a bag of worms.
This results in some unintuitive behaviour with the timerCHOP. When the timer is inactive the index is at 0, At the moment, the moment when we start it it jumps to 2 (which you are aware of and fixing.) I would argue that the timer, when intitialized should stay on the first frame (be it 1 or 0, idk) and not an, in the current setup, non-valid value.
Instead I expect:
Initialized: Running == False, Index == 1
Press Start: Running == True, Index == 1
Next Frame: Running == True, Index == 2

These are some general thoughts. I am inviting others to give their ideas and insight on this theme as right now I feel like the timerCHOP is not as reliable as it should/could be.

And a small RFE: I think there is not Cycle End Alter Channel that is selectable. Would be good to have :slight_smile:

It depends. There are two cases actually. Case 1 is your audience sees the state after the initialize is done and the timer is “ready”, then you hit start, and at that time you want/expect to see a change immediately, either a sim goes ahead a frame, or a movie plays the next frame, or you switch from a cue card to a live camera. i.e. you see a state change the frame you hit start.

Case 2 is that you expect to see the first image or the initialized state of a sim on the first frame when running is on, like in a case where you are cutting from an entirely different scene, possibly with a different timer, or controlled by a external switcher.

We do want both cases, and maybe we add a toggle to select which of the two behaviors.

analogous to a race where the gun goes off and in that 1/60 second, do you expect to see your athletes moving or not. Life in the world of discrete times.