howie's picture
howie commented on howie's Discussion, “Turning off nodes

thank you - both, this is very helpful

cremaschi's picture
mic commented on howie's Discussion, “Turning off nodes

I agree with the solution suggested by Bodysoulspirit. But I suspect that unnecessary "get image size" node are triggered anyway in his schema, even when resizing is not required, every time a new frame reaches "Blend images" node. Probably "get image size" is much less computational requiring than "resize image" of course, but it's possible to skip it also. Moreover, "resize image" also is always triggered whenever the new frame has different dimensions.

This way should improve the solution, triggering "get image size" and "resize" just when strictly required (caveat, not tested):

Bodysoulspirit's picture
Bodysoulspirit commented on howie's Discussion, “Turning off nodes

There is a feature request to turn off nodes.

Right now you can put another select in front of the chain, and leave one port empty, and add an Allow Changes node to prevent unessery events from entering the resize node.

See joined comp.

howie's picture
howie posted a new Discussion, “Turning off nodes

Turning off nodes

howie's picture

Sorry if this is basic question _ still got many gaps in my vuo workflow.

Im using a select input to choose if a video frame is passed through a resize or not.

When its not being resized i would like the 'resize node & friends' to stop processing.

Is there an easy way to do this ?

George_Toledo's picture

I don’t think this is a feature request type scenario in that there is no way to render movies and have a workflow where the user is previewing the output they are going to get. Does it really make sense to open it up to voting whether or not the window should match the dimensions being sent? Or is this just a bug? Maybe you all are right though, just throwing that line of thought out there.

George_Toledo's picture

The QCTV code example has cocoa based code that shows how this could work.

But also, can’t the window spawned just match the texture size it is being sent? There doesn’t even have to be anything fancy if the output window just went ahead and matched the input res when the composition is initialized. I think it is arguably bug-like behavior that it is currently somehow arbitrary.

jersmi's picture

Thank you, that's helpful, I'll dig in. So far with this comp, having the Vuo 2 Comp Loader open with Show Events selected is crashing the 2beta4 editor after 20-30 secs....

Ps. no love trying to use an iphone to create this response.

Bodysoulspirit's picture

Thanks mic, the workaround to use fire on start + fire periodically works.

So the problem does not seem to happen because the image is being loaded into the composition I guess.

Mmm, problem is for image protocols you should use "Allow Periodic Events" instead of "Fire Periodically" (for example for screensavers).

But solves my problem for now ;)


cremaschi's picture

A question to Vuo team. Why does this comp show the hiccup as well? My guess is that it shouldn't, as "allow first event" clearly stops all incoming event after the first, so "make image layer" evaluation shouldn't be delayed.



Vuo is more than nodes and cables, it's a community! Feel free to browse or add your voice.

Browse Discussions

Start a Discussion

Browse Feature Requests

Suggest a Feature

Browse the Composition Gallery

Share a Composition

How can I get notifications?

Learn more about the community

Learn more about Vuo

Vuo Announcements

Sign up for the Vuo announcements mailing list to get news and join the community. We post about once per month.