I’m not sure what to think about this. It seems that if the number is large, it cooks differently.
It doesn’t really need a large value either; it is noticeable at 50k.
Even if you bring the number back down, it still results in a steppy slope.
I just tried it on three different computers, Mac and pc in three different versions of Touch and had the same result.
Maybe this is a bug but maybe this is how it has always been?
It’s not just speed; it seems to be any changing chop value that is changing.
I have often thought about what the actual float value limit is for samples, but didn’t expect it to throttle performance based on value size.
I was hoping to drive some videos with a value that never looped, letting the moviefileIN TOP deal with seamless looping in the TOP. But after running for awhile it starts to get really steppy and unusable.
I’ve played with something similar a while ago and chalked it up to floating point precision issues. I’m making the assumption that TD uses floating point numbers to track the timeline.
tl;dr: This is framerate dependent and you can get rid of most of it (up to by switching to 32, 64, 128, … frames per second. It’s because 1/60 is not representable in binary without errors (see screenshot below). However I’m not entirely sure this will fix your video choppiness, cause we’re talking about a very small error value unless you’re fast-forwarding at a crazy rate.
As TD calculates the time elapsed in each frame, some frames will “drag” and some will “rush” so that, overall, you’re still somewhere close to the correct current time. Dragging frames will show a slope < 1 and rushing will show > 1.
The error then gets amplified with larger numbers, as more bits from the mantissa are allocated to what’s left of the decimal at the cost of what’s to the right of it. Even with a simple Speed CHOP going to a Slope CHOP, you can see this error start increasing as early as 20 seconds in:
Changing to a framerate of 1/64 for example makes each frame take up 0.015625 seconds, which can be represented without error up to approx. 524,300. Checking the same setup at 64 FPS, it now looks like this (notice how it’s completely flat until we hit ~524290):
