How to stop flow down a branch using a boolean?

vvvv beta question
1

I have two textures and I want to use one or the other. They’re both complex calculations and I only want to do one of them so if I’m using texture A I don’t want to do the calculations for texture B and vice versa. Another forum post asks a similar question and switch is the suggested solution but I don’t really think it answers the question - at least not for what I’m looking for. Since both textures are feeding into the inputs, switch doesn’t help me much with this. I want something to trigger the calculation of the one or the other, not do both calculations and then throw one of them away. Since VVVV works by data “flowing” down channels, it’s not clear to me how to get the data to flow down one channel and not the other based on a boolean. I’m sure it’s not that hard, but I’m just getting started with VVVV so I’m still scratching my head on that one. In Max I think you can use Route. Max gives a bit more control over this flow since they work off of discrete messages which you can choose to send or not send. VVVV has no such concept - everything flows and you don’t have much say in the matter and I’m not sure how to stop that based on a boolean. Is there some suggested idiom for doing this sort of thing?

2

i understand why you would not want to use the switch on the textures (because both would be calculated), but why is Switch (Value Input) (or equivalent in other categories) not an option for controlling the flow of the source data?

edit: oh, or do you mean that you have a feedback loop scenario:

if that is the case, then i do not understand this:

3

Please post (a simplified version of) your patch, makes it a lot easier to understand your problem and to give some hints.

4

Okay, here’s an example. There are two expressions being fed into a switch - a square and a cube. Since the switch is zero, the square is passed through and the cube is thrown away after being evaluated needlessly. No big deal for a square and a cube but imagine that both calculations are extremely time consuming calculations. You don’t want to do both of them and then throw away the results of one or the other but how do you avoid that? In Max you’d use Route (I think that’s the name) which only sends a message on one of the outputs based on the input. All the other outputs sit quiescently and do nothing. In other words, the decision as to which execution gets performed occurs after the decision as to which one is desired - not before. In VVVV you don’t have that control - or at least I’m unaware of how it works which could very well be the problem since I’m very new at all this. It seems that execution always flows downward. I like VVVV very much but the flow of control seems a little harder to piece out than it is in the much more discrete message based world of Max. Sometimes that’s good, sometimes not so much.

example.v4p (6.1 kB)

5

without having a look at your patch: there’s a switch (Value Output), too.

6

Why don’t you just switch what values go inside the Expr (value)?

To turn ‘heavy’ nodes of when you don’t need them, just switch the input spread with something that has a low spreadcount, or in your case, easy calculable.

7

West, the decision has to be made for every member of a spread so I can’t switch into or out of a spread case at each value. As far as diverting to an easier case, that’s essentially what I’m asking - how do I divert flow of control from occurring on the more difficult branch when I determine that I can get by with the easier calculation?

Perhaps I should be more specific - I have LOTS of lines, a few of which need to be clipped to the renderer. The vast majority of them can be passed through with no clipping at all so I don’t want to do the clipping except when necessary.

I’ve attached something that might work. Essentially I use an outbound switch at the top and an inbound switch at the bottom so the difficult calculation is neither pushed to or pulled from as long as the switch stays the same value. Since most lines require no clipping, the switch will stay 0 most of the time. I’m hoping that somebody can verify for me that this means that the right branch won’t be executed - I can imagine a case where VVVV just recalculates with 0 again even though there’s no way I can figure out to test that theory. Is VVVV smart enough to know that if the right branch stays zero that it doesn’t have to recalculate that branch? I’ve read that VVVV works off a pull model so perhaps if the switch doesn’t request the information, no execution will be done in which case perhaps I can get rid of the top switch. Is there a good test for whether execution travels through a particular branch even when the calculation might be precisely what it was on the last tick?

I’m just hazy as to the precise mechanics of evaluation in VVVV. Is there a good reference where this sort of thing is discussed? Thanks for all the help I’ve receieved.

example2.v4p (4.3 kB)

8

Some stuff that might help:

https://discourse.vvvv.org/t/1265: @gregsn gives an in-depth explanation of vvvv´s inner workings.
It is rather old and some things might be outdated but nonetheless a highly interesting read.

I think since then the S+H and Switch nodes have been optimized to stop upstream nodes from being evaluated by the graph, but some nodes like the Animation nodes (e.g. LFO (Animation) , Damper (Animation) )) have some kind of internal state and are calculated nevertheless.

Ever since I started using vvvv people wish to be able to completely “turn off” nodes, subpatches, branches of the graph etc. pp. see for example:

@Kalle)) has put together a wikipage with some ((performance optimization tips.

In addition to that:

  • most if not all primitives in the DX9 node category like Quad (DX9) have an Enabled pin use this to disable the node if the object is not rendered.
  • same goes for effects like Constant (EX9.Effect)
  • always put a Group (EX9) between the objects and the renderer and disable it too, this further improves performance though I can´t exactly say why, it´s just based on experience. Maybe someone else (@joreg)), user:gregsn, user:tonfilm, ((user:elias) can elaborate on this?!

To see how those measures effect perfomance use the debug-mode.

There are most definitely even more “tricks” but none that I can think of right now.

hth

9

Thanks so much everybody! A wealth of information for me to start digging into. I love learning new stuff so I’m excited to get started and really appreciate the words of wisdom.