Not sure if this should be a separate feature request from Lambdas/closures — ability to pass nodes into other nodes, but this seems like a first easier step towards that if I understand that request correctly.
Be able to just fetch and render saved Vuo Protocol Files.
QC had a “Render in Image” thing if I’m right.
Also, a Vuo Composition Vuo Type, so that we can scan folders for them to pickup random ones, and drag and drop them on window compositions and fetch their URL’s.
Mockup :
Are you thinking of QC’s Composition Importer? Fetching and rendering Vuo protocol files would require compiling the composition, which would increase the size of exported apps/plugins considerably. As an alternate, simpler solution, we could investigate creating a Vuo node that acts as an FFGL host, so the composition can run FFGL plugins. Then you could export each of your Vuo protocol compositions as FFGL, and load them into another composition as FFGL.
The difference between the “ability to pass nodes to other nodes” feature and the “composition importer” feature is that, in the former, all of the nodes being passed in would be part of the composition (i.e., they would appear somewhere on the canvas).
Haha yeah I guess Composition Importer, don’t remember the name, haven’t used QC for years, but remember one could do that.
FFGL sounds cool too !
Would also remove the compiling time I guess ? Allowing faster switching between effects.
Although, I just exported an FFGL to see its size, I get about 22mo for an Image Generator FFGL.
And a the Vuo file 22ko.
By how much would it increase the size of the exported app / plugin ?
How many bundled FFGL effects of about 22mo would it take to exceed the version with the compiler included ?
I guess both solutions could be great could they not ?
Depending on the case.
If used in Vuo, Fetching Vuo composition directly would result in light files, but with compiling times, so I guess one would need to use something like “Is Image Populated” before switching to a new effect. I also guess it would require less research and work for the team, since it would be pretty the same as loading a sub-composition ?
If bundled with an app, FFGL or direct Fetch composition, depending on the amount of effects bundled ?
Both sound cool for Vuo.
Why not both possibilities ?
I guess it would still require different nodes for each protocol type, so that would be like 6 nodes in total ? (3x Fetch Image Protocols + 3x fetch FFGL).
The difference between the “ability to pass nodes to other nodes” feature and the “composition importer” feature is that, in the former, all of the nodes being passed in would be part of the composition (i.e., they would appear somewhere on the canvas).
Ok, but then I don’t really understand the difference between that, and pasting saved compositions as sub-compositions ;) Sorry I’m having a hard time understanding that request it seems ;)
For clarity, let’s limit this feature request to only inputting FFGL plug-ins into Vuo. That seems the most direct and efficient way to gain the the desired functionality.
When exporting plugins and apps, Vuo includes whatever libraries and resources are used by the compiled composition, so the size changes depending on what the composition does. For example:
(An additional feature request could add the ability to export a group of compositions to a group of FFGL plug-ins; then that group of plug-ins could share most of their modules.)
You can view which libraries Vuo choses to bundle by right-clicking on the FFGL plug-in and selecting “Show Package Contents”, then navigating to Contents > Frameworks > VuoRunner.framework > Modules.
If Vuo compositions can be an FFGL host, then when you export that composition as an app or plug-in, it won’t noticeably increase the size of the exported app or plug-in. When the composition loads an FFGL plug-in, that FFGL plug-in has already been compiled and already includes all the runtime dependencies it needs. So, no extra compile time.
Ok, let’s go with FFGL and see how that goes ;)
Have updated the request title.
Thank you
Thank you for changing the name to clarify the FR. I’ve opened this for community voting.