Origami added a very nice UI feature to QC regards macros whereby if the cursor is over one and you hit the period key it toggles the macro between local (and editable by double clicking) or virtual.
So in terms of Vuo, if I understand correctly, that means having a UI thing to make a composition-local subcomposition available to all compositions or to go the other direction. OK.
In this feature suggestion it states that local sub-compositions would appear in the node library but only for the composition they exist in. This suggests re-use. Would altering one instance of a local sub-composition (let’s call it a ‘Vuo macro’) change all other instances of a Vuo macro? Or would the node library create a new local node with duplicated node title and “copy n%” appended to title (like copying a layer in a drawing or paint application where n% are sequential integers).
Also would the node library indicate in some way when a node is local i.e. a Vuo macro not a sub-compositoin? I can see an argument that says Vuo macros or ‘local sub-compositions’ have no need to be in the node library until they are converted to sub-compositions, available system wide.
I would also like to see nomenclature that avoids confusion between local sub-compositions and sub-compositions for obvious reasons. Macros would suit me, it’s a pity sub-compositions is already taken though, as it would be more logical to call local sub-comps sub-comps and what are currently sub-comps something else like virtual-nodes or macros. needs some deep consideration i think :-)
In terms of Vuo, the main thing is being able to explode a user sub-comp into a local version that can be modified as local macro as opposed to modify the node ‘class’ or base file of the user sub-composition (which is what we can do currently but it effects other instances in this composition and all Vuo compositions using it). I’m using the word macro here to mean something like macros in QC, much like this feature request is. In QC parlance, it’s about conversion from virtual patch to a macro and back again (if macro remains unaltered I think is how it goes). I guess until we get this feature in Vuo I’m not sure what to call it, so will refer to as Vuo macros for now.
Typically it is used in Origami to expose inner workings of the Origami virtual patches.
EDIT: I’ve checked behaviours in Origami:
If you use the “.” key in Origami to convert virtual patches to macros and then change the macros internally, they need to stay as a macro if you want the changes to persist. If you convert back to the virtual patch the macro was seed from using the “.” key, all changes are dumped and it returns to the virtual patch the macro was seeded from. They do toggle b/w virtual and macro while remaining unchanged inside.
You cannot convert any existing QC macro to a Virtual Patch just by hitting the “.” key with Origami patch installed.
Vuo team would probably want to decided those implementation details for yourself to suit Vuo scenarios but the Origami team have done an excellent job improving day to day speed of use building comps in QC. The sorts of prototyping Origami users do in QC typically involves hours/days of laborious building up of interactions from simple elements and images so little time savers go a long way. The single key keyboard shortcuts (a-z, +, -, *, /, etc) are brilliant even working over patch ports and adding patches inline and rewiring the composition. Excellent IDE helpers, all worthy consideration for Vuo I think.
Would altering one instance of a local sub-composition (let’s call it a ‘Vuo macro’) change all other instances of a Vuo macro?
Alastair, I believe modifying a global (? non-local) subcomposition would still affect all uses of it in all compositions, and modifying a local subcomposition would affect all uses of it within the one composition in which it’s used.
Are you suggesting a third kind of subcomposition that can’t be reused — where copying it creates a separate unrelated copy — and modifying it has no effect on any copies?
I can see an argument that says Vuo macros or ‘local sub-compositions’ have no need to be in the node library until they are converted to sub-compositions, available system wide.
What would the argument be? I’d think you’d want it in the node library so you don’t have to go hunting through the composition for an instance to copy and paste.
What if Vuo added any other compositions in the current directory to the node library, like Max does? Or, say, any other components whose filename begins with _?
@ajm, to make it easy to spot the top-level composition within a directory, we were thinking that subcompositions would go in a subdirectory called Modules (or something). Sound OK?
Are there any performance hits to having sub-compositions?
@cwilms-loyalist — When starting a composition, no, the opposite. The time from when you click the Run button to when the composition window appears is shorter if you use subcompositions, compared to putting everything in one flat composition. This is because subcompositions are compiled separately / in advance, so there’s less work to do when the Run button is clicked. It only has to compile the top-level composition, and can use the existing compiled subcompositions assuming they haven’t been modified.
While running a composition, there is a tiny bit more computation done when executing a subcomposition node compared to a regular node, and in a composition that’s using a large number of threads (>60) the subcomposition node may have to wait in line for some fraction of a second before it can execute. Whether this makes any practical/noticeable difference in performance would depend very much on the composition, also on the hardware.
Alastair, I believe modifying a global (? non-local) subcomposition would still affect all uses of it in all compositions, and modifying a local subcomposition would affect all uses of it within the one composition in which it’s used.
Are you suggesting a third kind of sub-composition that can’t be reused — where copying it creates a separate unrelated copy — and modifying it has no effect on any copies?
Yes, im suggesting when inline sub-compositions become a thing (effectively window in window was something I wireframed yonks ago in pre-alpha days) — or even before then — where sub-compositions are not so much Virtual Patches in QC language but just equivalent of QC Macros and copying them just creates a new instance that may be varied accordingly with no effect on the original node from which the copy was instantiated.
There’s a bunch of situations I’d use that in. Personal Text Layer nodes where I want to use something I’ve got already got going but then tweak it inside a bit to do something else, like round off or smooth a number value input that’s irrelevant to the original sub-comp/macro I copied it off because it doesnt have a separate numeric value input.
So yes that makes three kinds of sub comps, but really two kinds, the kind I’m talking about, macros in QC-land, and the ‘node class’ type of sub-comp you’re talking about that can be called up in the library, reused and rewritten once to see changes ripple through your composition / entire composition library.
Thinking that through some more, you might want that library or ‘node class’ kind of subcomp to be universal, either local comp constrained or global for all Vuo comps that user has, and the way they drag it onto the graph determines if it’s local or global in scope. Holding “Option” key while dragging from the Node Library or hitting “Enter” key while selected in the Node Library makes it global for instance. EDIT meant a modifier when hitting “Enter” key. (eg. “Shift” + “Enter” key).
Clicking Period Key while cursor is over a ‘node class’ subcomp devolves it into a simple macro environment with no implications on other instances when it’s changed inside. And vise-versa dumping any internal changes when returning to an existing node class.
Would need some kind of subtle UI indication of scope i.e. itself/local-composition/global.
Square corners ⇒ isolated;
round corner ⇒ local sub-comp;
chamfered corner ⇒ universal sub-comp.
Hope that makes sense.
@useful_design, I created a FR on your behalf: Option to edit subcomposition without affecting other instances.
Chosen to be implemented. (Already implemented in fact, to be included in the next major release. I forgot to mark it earlier, sorry about that.)
Awesome. Wondering if this will include anything like Kineme Spooky Send/Receive, or some elegant way to port data out of sub-(sub-sub-sub) comps to the root level and beyond.
Awesome @jstrecker. So have you already implemented global, local and group sub-comps/nodes (.i.e all three use cases for a container node listed in Option to edit sub-composition without affecting other instance)?
I guess if there is live editing for local sub-compositions it will serve half the purpose of group nodes (known as Marcos in QC), certainly will speed things up a LOT.
So excited to see so much promised for Vuo 1.3.
Chosen to be implemented. (Already implemented in fact, to be included in the next major release. I forgot to mark it earlier, sorry about that.)
Cool!
[@jersmi] Wondering if this will include anything like Kineme Spooky Send/Receive…
No. I think that’s covered by another feature request, Super cables.
[@useful_design] So have you already implemented global, local and group sub-comps/nodes…
We have not yet implemented the feature request Option to edit sub-composition without affecting other instance.
We have implemented the “global” and “local” levels.
~/Library/Application Support/Vuo/Modules or /Library/Application Support/Vuo/Modules, then all compositions can use the subcomposition and all compositions see any changes to it. — same behavior as nowModules folder next to a composition, then only that composition can see the subcomposition. Other versions of the subcomposition can be placed in Modules folders elsewhere in the filesystem and are not affected by the changes to the first one. — new behaviorThanks @jstrecker Vuo 1.3 is going to be a mammoth release by the looks of it.
Please consider ‘macros’ or Group Nodes as a high priority for composition tidiness, and I suspect for Editor run time performance too? To my way of coding it’s as important for legibility and coder comfort level as the canvas notes (which will be coming in 1.3 I believe, exciting!).
On the Modules folder, would all Vuo compositions in any given folder share access to the Modules folder? In one sense this is a feature (shared non-global scoping of sub-comps) in another way it’s a kinda a potential liability: each Vuo comp (including version saves which is how many of us save our work) with sub-comps would require its own parent folder to maintain single Vuo file scope for the sub compositions.
Team Vuo have probably thought it all through better than me, but that did occur to me as a potential issue. I guess it’s better than embedding the sub-comp file in the Vuo file though which was how I kinda assumed it would work.
… embedding the sub-comp file in the Vuo file though which was how I kinda assumed it would work.
Thought that would be the case too.
Especially after Jaymie’s comment Another piece — “select a bunch of pre-connected nodes, right-click them into a macro and all publishing and cable connections are done for you” — doesn’t have a public feature request, but we’re already working on it and are planning to release it in Vuo 1.3.
I should perhaps read all the comments on all topics related to sub-compositions again but I wonder what the benefits are or why the Team decided to have sub-compositions saved in a modules folder next to the composition rather then just being saved inside the same Vuo code file … Maybe there are benefits but at first glance it looks like extra hassle no ?
EDIT : Oups sorry it seems I thought I was commenting on the simple group nodes into a macro feature request Option to edit subcomposition without affecting other instances — Group nodes just for organization, not for adding to Node Library for which I didn’t understand what the purpose would have been for the sub-compositions to be saved beside the main vuo file (I guess simple group nodes sub-compositions will be saved inside the main file itself). Sorry, may delete my comment.
Resolved in Vuo 2.0 beta.