A question and suggestion.

How do people handle sub-composition when it comes to distributing compositions. For example, I might have a number of subcompositions I've created and use regularly, they are located in my node library. When it comes time to pass the composition I'm working on to others it is easy to miss a required subcomposition ... or just time consuming to find them and test.

Suggestion, a new save or export choice which has an "include sub compositions" option.


As written here Option to

Bodysoulspirit's picture
Submitted by

As written here Option to edit subcomposition without affecting other instances — Group nodes just for organization, not for adding to Node Library, there will likely be 3 kind of sub compositions, global (the ones we have now), local, the same as now, added to the library but where the changes made will only affect this sub-composition and somehow a real local sub-composition, actually simply a group of nodes, more like the QC sub-macro.

While the last one, real local group of nodes will allow seamless exports for sharing (as Jaymie mentionned here : Ability to create composition-local subcompositions, for the others I don't know either.
I know there is this feature request about being able to use sub-compositions not located only in the user modules : allow modules to load from user and system folders from inside sub-folders, so I guess you could somehow link to them with the url like an image and bundle them in a folder with the composition using paths.

But I have always wondered if in the end compositions could not be some kind of bundles, like apps actually, with a part of them having the code, but that we could also bundle sub-compositions (password protected or not ((see Feature Request about protected compositions for sale purposes)), modules, images, movies, fonts etc).
These would be absolute shareable compositions.

Right now, it's a bit tedious

MartinusMagneson's picture
Submitted by

Right now, it's a bit tedious to do as you'll have to dig out the dependencies manually. While a save/export to X function probably would be the easiest and quickest way to handle it, I would more like to see a library/dependency manager inspired by the Processing kind. Ultimately with a few additions that could make financial sense for Vuo and the community as well over time.

I at least swap out computers relatively often, so having Vuo linked to my account, logging in, and automatically pulling all my compositions and dependencies would be fantastic. Adding to this backbone is the possibility for creating a platform that will be beneficial for both team Vuo, contributors and users.

If you have 4 categories; Official // Pro // Community // Private, it should cover most of the bases. This way, the editor would also be able to be separated from node development in itself, making for a more continuous development/upgrade cycle. Instead of a base and pro version as it is now, you could pick and choose which (pro) features you need. Giving contributors a way to earn money if they wish would give an incentive for developing for Vuo - perhaps with a vetting process to list it in the official or Pro category. This could also ease team Vuos workload on much sought after node sets, and free up time to do core functionality/efficiency if external developers can see they can get something out of it.

I know that the option for an in app "store" would seem appalig for some, as the VJ/Creative coding communities at large are based on a huge effort of sharing, creativity and openness. On the flipside of that though, is the ability to actually put money back into the community and the application as opposed to a third-party store (that inevitably will come when Vuo grows large enough) which puts nothing back into the community or application apart from "exposure".

This may have gotten a bit more philosophical than intended - but if the ideas about this are in its infancy, it's well worth to think about.