Currently, when you make changes within a subcomposition, the changes apply everywhere the subcomposition is used (every instance of the subcomposition as a node in a composition).
This feature request is to add the option to edit an individual subcomposition instance without affecting others, and without future changes to others affecting it.
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…
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.
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.
I guess i’d go further and say the idea of this feature is simple “macro” (in QC terms) not a linked file. All the code is within the parent Vuo file. It’s just for making graphs more readable and to reduce Editor screen redraw time when running the comp — especially in debug mode or with value printers showing.
PDF of these two images which you can edit in AI if you have it installed. Sub-Graph Demo p3 copy.pdf (348 KB)
Video visualising and explaining the expansion and collapsing geometry with my reasoning.
All this is from Sept 2011 and not particularly polished as far as node look goes, more about the expansion/collapsing. The wires have three types, values (solid line), events (dotted) and lambdas (dot/dash lines) which in 2011 was a very exciting idea/prospect that Vuo team were hypothesising about. Lambdas are common in functional programming languages and in Vuo is the concept of nodes outputting ‘code’ not just ‘values’ to be passed to other nodes which then executes the code on data (or more code!) available at other input ports.
I also worked up ideas and QC prototypes for sub-comps that would be window in window and you could pan inside the frame to see the full extent if they didn’t fit all nodes in the size of box you had. I guess that means either fixed subgraph box sizes or user adjustable frame size for the macro nodes in expanded view.
Hi @jstrecker. Could we please change the title of this FR to more accurately indicate what some of us are after with this: a basic Marco in QC terminology node or “Group Node” as @cwilms-loyalist called it here.
Seems like there is a complex issue around events filtering on input ports that may apply differently in each of the three kinds of sub-composition concepts floating around now.
If i’m right in summarizing those three are:
Current case of sub-composition where the Vuo file appears in the Node Library. When you edit the master file for the sub-comp it changes all the instances in other Vuo files that use it.
New concept of sub-composition that also has edit in one instance and replicated throughout all instance but only in any given Vuo composition (local sub-comps).
Group Node which is for reducing screen clutter and speeding up Editor redraws when a composition is open in Vuo Editor (this request).
As mentioned elsewhere, would need some kind of subtle UI indication of scope i.e. itself/local-composition/global. Suggestion:
Round corners ⇒ isolated “Group Node”;
square corner ⇒ local sub-comp (appears in Node Library window under a “Local Nodes” heading);
chamfered corner (no difference in appearance to regular nodes in the UI schema in the illustration) ⇒ universal sub-comp (appears in node library and is available in all compositions).
If you have sub-graph editing in a window in window situation as I’m re-proposing (maybe that should be another FR for itself) then I think you’d need to have Vuo Editor notify users of external changes to the universal sub-graph when they open a new Vuo file that uses a universal sub-composition that has been changed since the Vuo file was last opened. I’m not sure how Vuo handles that situation at present.
Also I’ve previewed a few of the UI improvements I’d like in these images, should I individually list them as FRs or is that not really something Kosada are focusing on ATM?
Eg 1. data splitter node on cable as a simple ‘dot’,
2. different line styles for cables of different data classes: event, data, lambda (could be expanded to include one for Lists of Lists datatype). These line types are common in working drawings in Architecture/engineering and in maps for a good reason, improves readability immeasurably. It’s easy to distinguish lines from one another and filter out what you aren’t looking for. Also good for Colour Impaired vision people where coloured cables aren’t of so much use.
It might be worth making mention of the fact that macro/group/collapsed nodes should be live-editable, unlike the current subcompositions. It’s really time consuming atm to make changes to a subcomposition while there is no data coming into/out of it. Saving, re-opening etc to see changes effect.
Hi @bLackburst yes, good point. That was certainly one of the intentions of my window in window mock up show above.
I used to make QC layers for BonixTV/mimoLive and at a certain point you had to add all the protocol layer stuff and save the file and open it in BonixTV/mimoLIve to test it, but at least you could keep the file open in QC and keep saving it and just reload it in BTV. Much harder though not having live testing. That’s part of what makes visual programming attractive after all.
If i can get a prototype working of the pan and zoom I’ll do it. I attempted it back in 2011 and it was too hard for me in the end in QC at that time. I had simple panning and cursor states changing with modifier key states for pan and zoom in/out like with Adobe products and 3D apps. But when I added the zoom functionality into the prototype it got way messy and slow which defeated the purpose of showing how cool and slick it would be. Maybe I should attempt it in Vuo (or Origami Studio!) and see if performance and functionality improves? Anything involving prototyping maps with zoom that has to track object locations is hard work in QC/Origami… I’ve tried with several projects and I end up giving up. Nobody else has ever posted anything that has succeeded to Origami FB page either.
I just pledged 40 votes to this but the distinction between this and this https://community.vuo.org/t/-/5345 isn’t perfectly clear to me, which tells me they should be merged together and managed in a way that fulfills expectations the best. We just need qc style macros.
The way I read it there is currently one kind of sub composition which is global and you need to edit it without published inputs and outputs being any use while you edit. Meaning we can’t live edit without having a parallel test rig composition and cutting and pasting edits from the test rig to the global sub-composition file to be saved for use elsewhere. Erk.
Whereas I want three kinds of sub-compositions.
Global — effects all instances in any Comp Vuo opens if the subcomp is actively loaded in a Global Modules folder
Local — effects only instances within the Open composition, always belongs to a single composition and if copied to a new comp then is a new thing and belongs to that other composition.
Group Nodes | Macros — effects only a single instance and if that instance is copied to elsewhere in any comp it is completely independant of the parent sub-comp and any changes to it or the Group/Macro it was spawned from have no effect on the other.
In addition are two other desirables: (maybe I need to make these as separate FR to make it transparent that they are part of the concept)
(i) Live input and output state for editing sub-compositions, at least for case 3 but preferably for 1, 2 and 3.
The easiest way for Team Vuo to do (i) could possibly be that a second Vuo window gets created with the sub-composition but feeding and sending data from whichever instance that was double clicked to open it (but then as a separate threaded ‘application’ maybe that’s actually pretty hard?)*.
A QC style down/up level mode in the Editor is the obvious way to do it, although would only really solve 3. Group Node | Macros not Global and Local sub comps (1 and 2 in list above). EDIT: As @jstrecker noted, there is already a FR for that behavior here: Open sub-composition in same window as composition
(ii) Nicer would be window in window for all types of sub-compositions in same Editor as I’ve illustrated above, but that could be a fair bit of pixel work for Team Vuo to wranggle?
.* This got me to thinking, maybe being able «new feature alert!» to send any VUO native value (event, bool, image, list, etc) to another Vuo composition would be a way to help make this subcomp testing thing more readily possible? Like OSC and Syphon rolled into one. Could be trialed behind the curtain for sub-compsotions and if it’s stable then exposed as a usable feature. Not to sure how much use it would be to users though given that Syphon and OSC are already available.
[@useful_design] Could we please change the title of this FR to more accurately indicate what some of us are after with this: a basic Marco in QC terminology node or “Group Node” as @Chris called it here.
Changed, rather verbosely. Hope that helps.
[@useful_design] Whereas I want three kinds of sub-compositions
Yes, your characterization of Global (current behavior), Local (Ability to create composition-local subcompositions, and Group Nodes / Macros (this feature request) is pretty much what Team Vuo is thinking, too.
I hope Alastair’s answer makes it more clear. I think you voted for the right one.
Usually with feature requests we try to split them into work that can be done independently. Like here, it would be possible for Vuo to have local subcompositions without grouping or vice versa, if the community had an overwhelming desire for one to be implemented before the other.
[@bLackburst] It might be worth making mention of the fact that macro/group/collapsed nodes should be live-editable
Consider it mentioned. Although we don’t have a public feature request for that, Ability to edit GLSL shader code in Vuo Editor has a similar need. So the ability to live-edit nodes (covering both GLSL and subcompositions) is in our plans.
[@useful_design] Nicer would be window in window for all types of sub-compositions in same Editor as I’ve illustrated above
Needs to be combined with ability for user to set ALL paths used by Vuo (System/User/Project/Module /Build/Products/Framework dirs at least) in Preferences menu. All of Vuo’s current (fixed) paths are completely wrong for our systems.
@adeveloper Can you provide some examples of why that’s needed and how that would work using a preference based system please? I’m not sure I understand the need or solution well enough to agree or disagree.
