Since animation nodes are probably some of the most widely used nodes in vvvv (Damper/LFO being good examples), all of them have autoevaluate flag set to true, which is quite annoying in big patches since even with switch/s+h they still run.
Ok you can set spread count to 0, but node is still evaluating, so it still doesnt cut graph properly (and it makes patches pretty messy)
In large patches it’s a real performance killer, so having an option to make them run only if needed would be really handy.
what leads us to general patch-deactivation…
if you could get patch deactivation, would you still want that feature on the animation nodes?
it might make them too verbose. would be good to have an example scenario where it would make sense…
Hi vvvvriends! +10!
This completely making sens on big subpatch where the is five or ten or twenty lfos . Especially when we are using part of the patch running and not the rest
It could be painfull to have to split a patch very complex just to obtain this result. So personnaly i would need the two solutions. ;-)
Other thing about lfos: we need a real built in lfo-once node from 0.0 to 1.0
and framedelay tricks are a pis-aller
on heavy patch or heavy loads in memory neither woei subpatch nor > framedelay trick are giving a pure perfect lfo once
Maybe it´s stupid,
but what about node-deactivation instead of patch-deactivation?
it would be possible also to deactivate patches, and avoid to copy an animation node in a subpatch to deactivate it.
it is not stupid at all. i mean in theory it would make perfect sense to argue that patches are just one category of nodes and further ask why they should have an ability that other nodes don’t have…
i am asking for application scenarios because i see a downside of putting such a pin on more or even all nodes: a performance penalty that arises by evaluating if nodes should be evaluated… i mean the more pins there are that specify that parts of a graph should or shouldn’t be evaluated the more calculations have to be undertaken just to get a go.
for the case that you don’t build up some logic to handle this additional task - like it is the case up to now - you will end up with a performance hit that is bigger the more pins decide upon this matter…
so the example with the big patch:
i doubt that putting an additional evaluate pin on each node will be helpful, since you would need to feed too many nodes with that info to disable a complete subgraph. it would be painful and look bad. it might get better when we reduce the amount of nodes that have such a pin to those that are stateful and therefore do automatically evaluate themselves even when the ouput is not needed. but still you would probably end up with too many connections that just mess up your patch.
on the topic of animation node features: maybe the simple animation nodes just should get some simple features like pause that nowadays are only available on the advanced versions?
Thanks Sebastian for the explanation,
i would vote for the pause pin for animation nodes…
completely nice with pause ! especially lfo one. built in behaviour would be really great. curve input also. like map interval input for a more complexe lfo node.
about node activation thats a real better approach. about auto evaluation, would that be possible to activate it thruth inspektor ? like this auto evaluation would be costless ?