Hey! I found two bugs in timerCHOP, one is reproduceable (see attached toe) and second one only happens in my original project so I’m attaching it as a screenshot. Both projects run at 60 fps w/o framedrops and settings for timerchop are identical, so idk why bug2 isn’t reproduceable. Anywaaay:
Bug1: python callback prints incorrect segment number when you set one segment to length of 0 (open textport in toe file and you will see that segment channel in timer chop goes 0,1,3 while textport prints 0,1,2)
Bug2: for 1 frame I’m getting segment number that is 1 greater that the number of segments that I have, you can see it in the trail chop on the screenshot.
Let me know if you need any further info from me.
timerchop_bug.toe (4.6 KB)
Hey, can I gently bump this thread?)
Hi Densi. No problem. We’re having a look. Cheers.
I can’t reproduce bug 2 without an example, but I’ve made a change to fix bug 1.
It will be in builds 2022.28910 and later.
The issue was that the timer CHOP does in fact show 0,1,2,3, although 2 is only a single frame,
while the callback for 3 was being missed.
Can I ask why you are using zero-length frames? They raise some odd conditions for the Timer CHOP.
I had a similiar issue, I suppose it is the same core issue. Having a time of 0 in a timerCHOP results in the onDone callback not executing.
This can be useful to sequence the execution of events for init, without having to do 2 different ways of sequencing. (if that makes sense).
Hey @rob we’re using it to drive the playlist where some scenes have certain duration and if the duration is set to 0 we simply skip the scene. This seems like a handy way to avoid using an extra “skip” bool flag or something like this. Is this not recommended to have segments of 0 length?
We do make some provisions for zero-length segments, but we may be hitting some edge cases.
ie: CHOP timer values on a zero-segment length should probably never be visible, but we stretch them to one sample.