Evaluate pin

There are two threads already about the need of the Evaluate pin for nodes that stem from VL.

Now based on that feedback I’d suggest to give every node this pin. Technically it works already (check upcoming alphas). However there is one question arising:

Do you know of anode that has an Evaluate pin already, which is not a patch? Such a node would now get a second auto-generated pin which might break this node. Please report if you know of any such node.

Also: if you think this is a good or a bad idea, please make yourself heard.
Do you think that this might be overly confusing? A S+H node for example would now come with a visible “Set” pin and a hidden “Evaluate” pin.

Thanks for your input!

1 Like

I think this would be a great thing, this would mean that I don’t need to subpatch hard calculations taking a single or couple of nodes which I only want to be executed at certain times or I don’t need to introduce another node solely for that purpose (less clutter). I only know I have couple of nodes which has pins called “Evaluate” but I can rename them. probably that 2 people who might use them wouldn’t mind.

Sounds like a good way to go,
I wouldn’t have any objections as for the naming and don’t think it would be overly confusing as long as the evaluate pin is hidden by default.

One question though. How does this affect pads?
If I have lets say a node that outputs a sequence, that is stored into a pad and then output to vvvv. Does not evaluating the uptstream node do anything for me considering performance?

It does, but it might still be quite heavy to copy your huge sequence from pad to output, which might still happen every frame that way.

nono. With Evaluate off the whole node will not do anything. No copying no evaluation of upstream connected nodes. Outputs stick with old values.

1 Like

@microdee: upcoming alphas now mark your Evaluate pin red as this pin is now reserved for our evaluate logic. Please test and rename your pin if you find the time.

1 Like

have several occasions where i gave my plugins an Evaluate pin.

how will the native evaluate work?

no call to evaluate, no sync-ing inputs, no flushing outputs i read. can i still do this from within the plugin if i need to? anyway to get a notification at the point, when the node would get evaluated graphwise? since onpreparegraph just gives me the general frame not the specific point when vvvv actually ‘hits’ the node.

think of the cases where one needs handle OnDeevaluate or OnResume. timebased or state handling nodes

first off one question: in case of this node sitting in a patch with evaluate off the node didn’t behave like wanted, right?
i just want to make sure that i am not introducing new bugs.
the only difference now would be that not only all parent patches can turn off the evaluation, but also the node itself can be turned off.
it is true that we could refine the plugin interface so that in the event of turning evaluation on or off (by parent patch or by node).
But for now i just would like to make sure that your nodes behave like before this change. To do this just rename your “Evaluate” pin to “Enabled” and do your custom logic.
I would like to treat the issue you brought up as something that can be solved in another iteration.
Think of subtleties like AutoEvaluate vs. OnPrepareGraph. And questions like when exactly do you want to get the OnDeevaluate or OnResume to get fired. Let’s just open another separate thread for that?
Would you mind giving the alpha version a try?

@gregsn while you’re at it. can you have a look at this?


you should now be able to remove your Evaluate pins and just implement the interface.

@bjoern: i did. sorry for the delayed answer…

1 Like


the framedelay example doesn’t care about the precise time.
i suspect that the OnPrepareGraph event is a call at the beginning of a vvvv frame. all instances get notified at once. the only way to know the time within the frame, when vvvv has traversed the graph and actually calls the instance of a plugin is the Evaluate method.
it’s not a big difference timewise, but i can cause issues when you actually want to rely on the order of the graph to do something in the plugin instances.

see example, all instances get onprepare graph at the same time, while of course differs and is in order of the graph.
.TestEvalOrder.zip (36.2 KB)

i’d suggest an per instance event on pluginhost OnEvaluate to be able to do the work necessary at the right time in the frame even if evaluate is turned off.
and by the way a OnConfigurate would be great too

other ideas:

public void Evaluate(int spreadMax, bool needsEvaluate)
public void OnEvaluate(object sender, EventArgs<bool> args)
where bool is whether the instances in set to evaluate or not

Here is how evaluation is implemented.
OnPrepareGraph calls

  • nodes that have autoevaluate set to true,
  • those that register at the mainloop.

If “AutoEvaluate” is set to: This leads to registering at the mainloop, checking if node and parent patches are enabled and if yes evaluating the outputs which leads to calling Evaluate.

Once such an evaluation of a node is triggered this typically leads to validating inputs and thereby evaluating the upstream graph, So often enough the first nodes that get called back by the PrepareGraph event lead to evaluating quite a big portion of the graph.
The vvvv user has no control over which nodes register first. So nodes should not depend on it. They should not depend on which preparegraph is called first. However they can be sure that Evaluate is called in the right order no matter in what order the PrepareGraph callbacks are called, since nodes evaluate their upstream graph.

Sooo. “i suspect that the OnPrepareGraph event is a call at the beginning of a vvvv frame.”
No they get called within the frame. OnPrepareGraph and Evaluate mix freely.

Always do your main work in evaluate. PrepareGraph is just for kicking of evaluation.

I am sorry. But i can’t see the real value of that feature request. You want to be able to trigger actions in a patch that is turned off. And those actions shall occur in a specific order. Why do you want to do something in a patch that is turned off? Shouldn’t you make sure that your node doesn’t do anything when the user chose to disable it?

nana, i don’t care about the plugins inside a not evaluated subpatch. the mechanism you seems provided is fine for that. it’s primarily about the case of a graph where some are set on evaluate, some not.

i’m talking about the auto evaluate pin that every plugin gets. with that one i can’t be sure to have evaluate called anymore. which to my understanding means i have no possibility to react on the moment being ‘pulled’ by the downstream node once the evaluate pin is off. even if i don’t want to evaluate (=do calculations) in that moment, there are sometimes still configuration tasks.

i might need an example for that. Currently no node (including builtin nodes) is able to evalaute itself if evaluate is turned off. They just don’t get called back by the system. But there is a way now to react on turning off and turning on. And you still can get called back each frame by the mainloop. So i would hope with that toolset you can do everything you need to.
If you have a good example we can discuss IPluginTurnedOff.EvaluateWhileTurnedOff(), which we would call back in that case where somebody is interested in the node’s output while it is turned off. Can’t promise, but this could be possible to implement. However it feels strange still. I would rather want to avoid this.

edit: ah and inputs would still hold data of the last frame where the evaluation was enabled.

just thinking that those nodes don’t depend on their upstream nodes while turned off. So hopefully the order of the preparegraph call shouldn’t be that important as they don’t interact with other nodes directly - and shouldn’t be that active anyway.

well i guess it’s just new territory here: until now there was no such case as a single unevaluated node except for subpatches. the behaviour was pretty clear. but what’s the intended behaviour with config pins? subpatches didn’t have that.

my implementations were always treating config changes apart from evaluation. which is also much easier since you just listen to the pinchange event. configuration vs evaluation since i considererd configuration ‘sourcecode’ and evaluation = execution/calculation.

maybe it’s not an issue at all with the native evaluate pin, if it disabled syncing of config pins or would fire the change event before evaluation is turned on again. if not one would have to stash the changes and execute them right before the first evaluated frame.

at what point is configurate handled right now? is it traverse graph upstream and configure, then traverse down and evaluate. or is configurate happening right before evaluate per instance?
in the first case, it might be hard to apply changes right before the evaluate is turned on, since that’s not known at that point, since evaluate might be triggered by some nodes above, which first have to be evaluated.

Config pins directly react on actions which is not related to evaluation per frame.
IPlugin.Configurate(IPluginConfig configPin) gets called.
This should even happen when the node is turned off.

Please have a look, if the alpha behavior is indeed a problem.

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.