# 22880: Value rounding

This isn’t a very new thing, but it’s getting more annoying as time goes on and happens regularly now.

Can you let me know what build you see this on? I can’t duplicate it on 23540. Also wondering when it happens, and if the Filter CHOP have any non default parameters.

Same here. Usually this happens when the filter is set to Gaussian

That particular case was build 22880, but I saw a similar thing yesterday with the Timer CHOP. Had it set to 10 seconds, and with the seconds ramp on (can’t remember the name, but the one that counts the seconds), it never actually hit 10 before it wraps around to 0.

I’ve seen this on a ton of builds though, does seem connected to filter a lot. On the bottom end can be bad as well where it falls into infinite underflow type thing.

@timer CHOP: in that case this should be normal: there is no guarantee a ramp of floats/a phasor reaches it’s max value usually. Think about sampling period/fundamental freq of the phasor. If they are in integer relationship it should at least have a stable maximum value, and not a different one each cycle.(but not neccessarily the exact max value).
Don’t know if there is some magic behind the scenes that is supposed to treat this (normal) behavior.
Usually one looks if the derivative of a phasor goes below 0 (for a rising ramp) to detect it’s reset point.
(hope all that hold true for TDs implementation of things. That’s what I’m used to from theory and the max/MSP world)

Looping, say from 0 to 8, should/will never reach its upper value. Analog or digital, like when your time-of-day steps from 7:57, 7:58, 7:59, it doesn’t step next to 7:60, it’s 8:00. Same with time codes.

So you’re right, Timer CHOP, when the Length is 8 and it is cycling, the value will never hit 8, and the fraction will never hit 1 until the cycling is ended and the final value is 8 and 1 respectively. Same with other CHOPs that loop.

And that’s why onCycle() callback in the TImer CHOP is useful, it’s called the frame that it loops.

So yes, it seems like the precision problem still remains with CHOPs that converge but don’t reach their target value. I thought we had dealt with this ages ago, so I’ll check with the programmers who are looking at this issue, might be a 32/64-bit thing.

Hmm, that might be a helpful note to add to page of Timer CHOP and any of the chops that can Loop values back. I wasn’t aware of that, and my first instinct was that it would hit the top value.

But I definitely still see this once in a while with the Filter CHOP.