togedge has the option ‘bang on create’ which results sometimes in funky effects when starting complex patches. i vote to set it to OFF by default as i expect the node only to react when my logic set it to 1 and not be itself.
is it just me finding this anoying ?
are you really sure that the upedge bangs on creation?
like i posted last year:
for me it’s only the downedge that bangs on creation.
TogTest.v4p (7.8 kB)
that makes it even worse, half working bang on create. that’s something hard to debug if things go wrong on startup.
good to know kalle…
yes, but that’s quite theoretical. i don’t care how bang on create acts on an unknown frame. i see it from a practical point of view…this node does something by default without being told… that’s why i started this thread
and i still think that different behaviour (banging only one output) to what the node usually does, is neither helpful.
a more general look at the problem, bang on create is a functionality for a special case and therefore should be off by default. or am i overseeing something ? maybe it is a feature used by most users, i don’t know…
i’m with u7angel on this. trying to judge unbiased i’d also say that defaulting create on bang to off is just the intuitively expected behaviour.
i am with you u7angel and will change the default. that means all TogEdge (Animation) nodes that already have been created will not change - only those that are newly created. (>beta23)
i will do the same for the Change (Animation) node.
and to all you resilient guys:
this topic has been discussed already in 2007 in just another thread:
i had the same feel to that, but it seems that we were wrong. at least we were wrong on that you would want this as the implicit default behaviour. obvisouly most of you would like to do initialization work explicit when needed.
Besides of the your judgements there is another thing that convinced me.
On resuming http://vvvv.org/forum/togedge-(animation) i noticed that most nodes with a previous input state(e.g. the simple animation nodes like LinearFilter (Animation)…) already behave that way:
The animation starts at the first frame value of “Go To Position”. This resembles the behaviour of an animation node that has been there for a long time, always receiving the same value at Go To Position.
to put it short: the missing past of an animation node can be seen as subsituted by the formula
“past = list of present” which is the most simple extrapolation idea one can think of…
In the future change and togedge will not bang. In that way they will also behave as if Input would have received a constant stream of values in the past (equal to that in the current frame)
so i found my way to be happy with such a default behaviour! ;)
great news, thanks!
"past = list of present " sounds interesting :)
yes, it doesn’t sound very promissing though…
so to all nodes:
if past = list of present then
all the best for the future!!!