- Prefers to be called
- Uses pronoun
- Perth Australia
- 8 years 2 months ago
- Last seen
- 1 day 10 hours ago
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 Jaymie 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.
I think port socket shape variations could add to readability. I'm certain line-types by cable object-type would (event-only, single object data+event, lists, one day lambdas!). They've been standard in complex engineering, maps and architecture drawings for a very long time because they work.
I was never a fan of the protruding ports, even though I understand the reasoning behind the decision (making cable-port connections more obvious than in QC) I think it's debatable if the logic holds water. To me it can still be hard to see if the angle is close to perpendicular and that could be rectified by making the cable arcs enter ports at a horizontal angle.
Various shapes that ports could take if they were rather than outside nodes but inside ports but open and on the edge would be triangular (normal), square (data), circular (lists and lists of lists), hexagonal (four sides of the hexagon) (events). Or any other permutation. (I don't like the aesthetic of it though so far).
Colouring wires (either randomly or by type) on selected nodes could improve readability as well as dots for events and dash-dot for lists. Although if screen notes or expanded sub-graphs (window-in-window that doesn't exist yet) had coloured backgrounds that could make random colours problematic for readability.
Oh man is colour space a complicated topic. Read Real World Colour Management (recommended) twice and struggled to explain to others who problems I needed to solve even when I did get much of it myself (now half forgotten). The conversions through multiple spaces and Applications invoking in different ways gets very tricky, but necessary to understand and use sometime, especially in print and proofing work.
Hi Jaymie. I kind of thought that was what my FR linked to above was all about. See the link for my latest offerings. Does your plan include window in window style of macro or QC style of level shift from parent into child and vise versa? p.s. very pleased to see you mention this is already being worked on.