Strange cyclic pin behaviour


please have a look at the attached patch.

Is this strange effect when changing the state of the cyclic pin a bug or do I something wrong ?


strangecyclic.v4p (6.7 kB)

hm. yes, it behaves a little bit strange.

let’s just resume what cyclic means: the filter should take the easiest way to reach the position on a cricle. the position can be interpreted like CYCLES.ANGLE. Everything you input in front of the decimal point is not of interest for the filter in cyclic mode, but only the angle is taken into account. at the end the filter may just decide to take a shorter or more effective way to go to the desired angular position, which just has the effect that the final output = input ± some integer. if cyclic is off the final output = input.

what should be the desired behaviour like?

when switching from not cyclic to cyclic nothing should happen.
i think this is working already.

when switching from cyclic to not cyclic the output has to change in most cases, so that the damper or oscillator will really arrive at the desired position.
up to now it just drives to the actual position in the given filter time.
maybe it should just jump a few integers in one frame so that this change is not noticeable if the output is used for a rotation (where also the digits in front of the decimal point have no effect on the visual effect). On the other hand if the value is also used for a translation the jump will be irritating / not be the desired behaviour.

what do you think?


check out the work around!

strangecyclic.v4p (9.7 kB)

hmm …

right - both versions make sense … depending on what you want to do !

so - not really a bug - you only have to understand why it is like this and how to deal with it !

Thanks for the workarounds !
Enclosed the workaround I was using meanwhile.


damperworkaround.v4p (11.1 kB)