Ability to create composition-local subcompositions

Feature Requests
,
1

Currently, any subcomposition you create gets added to the Node Library. This is good for general-purpose subcompositions that are meant to be used by many compositions.

But for subcompositions that you only intend to use in one composition, it would be better to keep them with that composition, and not have them appear in the Node Library for every composition. These subcompositions could be stored with the parent composition and only appear in the Node Library when editing that composition.

This would also make it easier to share compositions or move them from one computer to another, since you wouldn’t have to track down all the dependent subcompositions.

2

Isn’t there, presumably, a line of code that controls where sub comps are loaded from…and a line could be added to also load the relative?

I haven’t used that feature yet. Is there a node that loads them, or a file that you can point me to that I can look at modifying?

It seems like there needs to be an input port to control path, like the QC composition importer. That way someone can load sub compositions in a modular way, retrieving them from an arbitrary folder at runtime. I wouldn’t mind experimenting with adding that myself until it’s a core feature.

But maybe there is something with how compositions get loaded that would stop that from happening at runtime, like it getting baked into the file or something.

3

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. Round corners and square corners change to indicate state.

EDIT removing my PIP comment and placing in the other Feature request about full window editing of Sub-compositions. Very interrelated with this though.

4

Isn’t there, presumably, a line of code that controls where sub comps are loaded from…and a line could be added to also load the relative?

Yes, basically.

The other parts of this feature request involve loading and unloading subcompositions at the right time, making sure they show up in the Node Library for their parent composition and no other composition, making it work with the compiler’s caching of subcompositions and other modules, and avoiding slow performance and multithreading-related crashes.

The relevant source file is compiler/VuoCompiler.cc. The function VuoCompiler::installSubcomposition() would be a good starting point. Actually, if you haven’t looked at the compiler code yet, you might want to first take a look at an earlier version of VuoCompiler.cc, maybe from Vuo 0.9, since it’s more readable / less optimized.

5

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.

6

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 :-)

7

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.

8

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.

9

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 _?

10

@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?

11

@jstrecker: sounds good to me!

12

Are there any performance hits to having sub-compositions?

13

@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.

14

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.  

15

@useful_design, I created a FR on your behalf: Option to edit subcomposition without affecting other instances.

16

Thanks @jstrecker!

1 Like
17

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.)

1 Like
18

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.

19

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.

20

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!