Hello. I’m using damper to make linear animations and looks like it have really strange bug - sometimes when it must be stopped it still counting something. Screenshot attached.
i think that’s just never ending rounding in infinite algorithms like the dampers is. see thet the value is veeeery low.
but i’ll agrree that such behaviour cann be annoying. a way to avoid it can be done in a very small module:
value * multiplier (10000 for example) -> frac -> whole part output of frac / (same) multiplier
perhaps we should think about a limit or epsilon pin for those nodes.
I’m just using to values - 0 and 1, looks like it’s bugging when going from 1 to 0. Thx for the tip, i will try it. Yes, i think we need this fixed by default, because it can be really strange, especially for newcomers.
usually those errors of data are coming from someone else, an array boundary unvalid or exception violation. close or freeze others parts of your patch to determine from where is coming this 2.7777E horrorfull thing.
Damper is really strong and i had never such trouble with it. thats why i m arguing of someone else fault in the patch ;-)
the value just indicates an exponent
so this value means 2.773^-276 - like 0,000(…276 zeros here…)0002773.
i don’t think that this is a bug. it’s just the algorithm that will never reach its goal.
note that the display of values’ precision has changed recently.
+1 I think it should be considered a (minor) bug because it is mis-informing the user about what s going on. It really scared me in the beginning, then I got used to it.
S.
+1 have the same. this is beta26 bug. actually damper works well, but tooltip shows something his own.
note that the display of values’ precision has changed recently.
i think the damper behaves the same for years now. only thing that changed is that you can now see those very small values, because tooltips (and io boxes) aren’t limited to four decimals any longer. so it’s a feature.
in case i’m completely wrong, some dev might clearify things here.
I have to agree with sebl. Before, you just couldn’t see that the output had not yet reached zero, which lead to strange effects when comparing it to real 0.
An additional threshold/epsilon/whateveryouwannacallit pin would be very useful to make the damper more easy to handle in some cases.
what sebl said is right, gregsn improved the value display.
the damper works well for years, why change it only because you have better data display? instead you should have the idea that comparing something to 0 might be bad programming style. and the epsilon you are looking for is already at the = (Value).
of course we could add something like:
if (abs(value - gotovalue) < epsilon) value = gotovalue;
but thats a slowdown of a frequently used node…
Why is “comparing something to 0” bad programming style? I often compare a current to a target value to trigger different events at the end of a transition. No matter if the target is 0 or 9999.
unsurprisingly i would also argue that showing the precise value in the tooltip is a feature.
now you could argue that the damper should have an option, that when it reaches the goal after the specified filter time it should jump to that goal.
i sketched one solution that could be implemented within the damper. however you still need to convince me that the damper needs that behaviour.
an additional timeout pin would be needed to specify if you want that behaviour or the precise one. note that the sketched behaviour isn’t working well in cases where a damper comes from very far away… just set the goal to 1000 and after a time back to 0 to see the hard jump.
another option would be to switch to the goal when it is very near to it (via an epsilon). then however still another new pin (Epsilon) would be needed.
i am not so confident about all that. maybe it would be best to use the “bad programming style”: compare with = (Value) and set the epsilon to 0.00004999. this would be compatible with the standard precision of ioboxes. if you see a difference then the = will output false, if you see no difference the = will output true… however i am not so sure about setting this as the default behaviour of the = node. what do you think?
so feel free to participate in getting it right and feel free to submit patches that sketch the desired behaviour of any node…
Damper (Animation Timeout).v4p (10.0 kB)
Hi gregsn, thank you for your feedback on this topic!
First of all, please let me make clear that the filter nodes you designed many years ago are brilliant. They made vvvv superior in terms of automated animation to many other authoring tools and still do a great job for us.
From my point of view, what we are talking about is not some “bug”, but rather about how to make this essential node more “foolproof”.
Before I first recognized that the target value is not reached by the end of the filtertime I set, I thought there’s something wrong with the node. That was, because I couldn’t see that the output displayed is not the real output given, due to the IO Box being limited in floating point display capabilities.
Now the real output became visible but - at least for people not being that experienced in math - it looks somewhat wrong.
Personally I would simply expect the damper to having reached the target value EXACTLY as the time I set for filter time is up - no matter how accurate the approach is and I’m pretty sure most people who are new to vvvv and its filters would expect the same.
In fact, if a native timeout pin would be available, the first thing that I’d do is to set that option to ‘true’ after creating the node in my patch.
The idea of having an epsilon value instead of “Timeout on/off” wouldn’t help much I think and would probably lead to even more confusion, because then one would always need to find out the right epsilon to make it stop at exactly the given target time. Also, as tonfilm already mentioned, if you wish to have this feature, you can easily utilize the epsilon pin offerd by the “=” node in a second step.
Regarding the module you contributed: It absolutely does the trick and is quite similar to the method I used up to now to fix that problem. But it only treats the symptom wich initially lead to this thread.
Instead of having another additional module that alternatively lies beside the original node and that you need to understand in terms of ‘why does this thing exist?’, I would rather recommend to find an integrated, native solution, offering a smart preset that no beginner needs to take care of while diving into the wonderful world of ffffilters.
the module is meant as a sketch for a future implementation of the native damper. just collapse it and see if this is the node you want to have. don’t care about if this is a sketch implemented as a module or if this is a native node. don’t care about the name. just care about the behaviour, the pin namings, their defaults. is that how you would want the native node to be like?
if not feel free to do a sketch that i will consider as something that also could be a native node…
Your sketch reflects what I was thinking of. So yes, I’d appreciate the timeout function the way you proposed it.
Would you see any risks or do you have any concerns regarding the implementation?