To toggle a video effect, currently I am using OSC to get a toggle value which returns a boolean True when on, False when off.
I want that toggle to enable the Posterize Image effect.
The only way I could think to do it is to send the Play Movie to both options of a Select Input. One passes through the effect first, one doesn’t. I convert the boolean to integer with Scale, where True = 2 and False = 1. I use that to switch between the Select Input. It works, but is this the best way in terms of performance?
@jmcc Does Vuo know not to run video through the Posterize node if, downstream, it’s not used?
I know Quartz Composer used bottom-up rendering to achieve this efficiency.
In any case, you can avoid this particular problem by structuring so you use a Choose Output instead, and use a Select Latest node to, well, take only the latest and greatest.
That is the difference between QC and Vuo. Vuo is event-driven, so if an event goes into a node (even if it has no downstream connections) it executes.
QC was “pull” with lazy evaluation, as was Apple’s Core Image architecture which was something of a sub-set of GLSL for 2D images and present in all their video and image apps back in the day.
Like many other functional programming languages, lazy evaluation effectively optimises for minimal runtime code. There’s more to that than just triggering events or pull from a screen renderer patch, if I have a function which defines an infinite list of prime numbers starting at 2 and another function that takes that function and chooses, say, ten primes greater than 100, then when the second function executes, it doesn’t first generate that infinite list of primes (stack overflow!) it just executes it enough times to get the result of the second function. (Hope that makes sense).
In graphics terms that can mean a stack of multiple image transformations executes in one operation much faster than the same operations done in series one after the other. I’m not sure how Vuo optimises a series of transformations but I’m guessing it has some ways to do matrix multiplication of a set of transformations before applying the result to an image.
Vuo isn’t, though I recall in the pre-alpha days a debate was had about making (what was to become) Vuo “push” or “pull”. “Push” won out because it allowed for asynchronous operations in the same composition — "event driven as @jmcc explained it — so some code can be executing 120 fps while other parts are evaluating as fast as they can, but because of their complexity at a much slower frame-rate. Another point was made at one time that push evaluation could be converted to pull type execution with another layer of abstraction on top… but looks like there’s no call for that in Vuo at this stage.
In practice, I don’t find the ‘push’ of Vuo to be problematic, and if anything, is a little more intuitive than QC.
I think there’s two aspects here:
Issue here from @ooftv which is common to me—the desire to turn some layer, or processing on or off, which requires an additional two patches or more—in the case of a layer, I find I need to create a layer of 0% opacity and switch to the input (since simply turning off the layer doesn’t remove it from the rendering layer stack)
Efficiency, and knowing what nodes are running or not, and at what frequency. I think a neat solution for #1 might also solve a lot for #2.
and if anything, is a little more intuitive than QC.
sometimes people think intuition is somehow hard wired into us humans, it’s not though. to the extent we have six senses, yes it’s hard wired but most of what we describe as “intuitive” is 100% due to our conditioning. In some places a shake of the head means, “yes”, on the other side of the mountain range in means “no”. this is just conditioning and it goes way deeper than facial gestures in social groups.
same goes for our experience of software:
Windows vs Mac
Adobe vs other (or vs Macromedia fo those of us who were using graphic software in the 90s)
developer vs UI/UX consultant
musican vs linguist
intuition is in the mind of the intuitor :-) That’s why pan & zoom controls using spacebar ⌘ ⇪seemed like a no brainer to me on day one of Vuo and years on, we have spacebar panning but no zoom.
I think that even a push system can in fact be made to traverse the graph to determine whether there are any nodes down the chain…a reason to evaluate.
I believe this to be an implementation issue, not necessarily an “event driven”/“push” issue.
