Force IO from outside node + Node browser highlight local properties inputs and outputs

Problem A

When setting up a new object I lose productivity switching between the inner and outer context.

For example my current flow is:

  • I am patching in OuterProcess and I decide I need an InnerProcess. Ideally I would take advantage of vvvv real-time context and have real working data I can see in the tooltips and results as soon as possible.
  • I switch context to the patch definition to create InnerProcess definition
  • I go back into OuterProcess context and instantiate an InnerProcess node
  • I go into the InnerProcess and create some inputs and outputs and possibly type them
  • I go back to the OuterProcess and connect the inputs and outputs.
  • I now go into the InnerProcess and am ready to patch with real data

Problem B

When implementing interfaces I have to switch context to the interface itself to check the names of inputs and outputs, costing time and mental focus.

Feature idea

This has two parts

  • Propose from an outside context you can force add an input or an output to a node by Space+Click on the body of the node while creating a link.

  • Propose In the nodebrowser a new switch that shows local inputs and outputs for this node context.

    • They should appear at the top of the node browser list if this is enabled.
    • Inputs and Outputs will have a color highlight if they ‘should’ exist but don’t, either due to being plugged into the outer context of the node or because they should exist on an interface operation.
    • The inputs and outputs show the Member Operation they are on in brackets eg World (SetWorld) or Value (Update).
    • If those member operations already exist in the node they should be colored same as they are on the node.
    • If the member operation doesn’t exist on the node then creating the input pin from the node browser also creates the member operation

This will enable users to switch context less often when setting up objects or interfaces.

For the object case you can force connect all your pins to the premature object and then switch to the inside context one time and access those as ‘should’ be connected pins.
For the interface case you have the input and output names and member operations in the node browser and don’t need to switch to the Interface context to check them.

1 Like

Hurray for multiple patch windows…


at least this one step you can already skip by creating the node as shown in HowTo Make a node

we have this on our todo, unfortunately without ETA. we call them “Dummy nodes”. will be amazing even only for quickly sketching pseudo-code.

also regarding interfaces we’re aware that UX needs quite an overhaul.


Regarding multiple windows
I agree it’s one solution to this problem, would often be useful, definitely support it.

However looking left to right between two things is still switching focus for me and impacts productivity.

I know we have accepted multiple windows as relatively standard in our modern world but I think it’s a B grade solution compared to a UX flow that puts all the information available as you need it in one place.

Hi, the problem with this is that you have for instance state or context and you want to see that, then you have a view witch should take something from context and then display it, so basically you always have to work with at list two views whatever you do…I’m not sure that this can somehow be resolved…

For instance now I do a lot of react redux and I always have one VS code instance with view of page, the code view of component and another VS code instance with a code view of state manager…

Like right now when you work with gamma you have at list two instances open, one for help browser the second one for a project…

I guess maybe working with two-three instances of VL would be sufficient if thouse instances allow to synced editing of same documents, but also what I really like with vs code is a folder view of a project

You are right.
I’m always working with at least a Skia or Stride window open + my VL document.

So I’m already looking between two windows. But this is the same reason I don’t want to be looking between three.