Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Quest/Proposal] Local variables aka invisible links #50

Open
tebjan opened this issue Jan 28, 2022 · 2 comments
Open

[Quest/Proposal] Local variables aka invisible links #50

tebjan opened this issue Jan 28, 2022 · 2 comments

Comments

@tebjan
Copy link
Member

tebjan commented Jan 28, 2022

This feature helps to get rid of link clutter in patches. a link can also be represented by a name, aka local variable in programming.

the UX works like pads, but instead of writing into a class field, a local variable is used. at first, one source is allowed and many sinks, just as a normal link.

image

@gregsn
Copy link
Member

gregsn commented Feb 3, 2022

Great one!
This reminds me of another idea that came up some years ago. It went like this:

Let's say we want to feed a sort of context to an operation from the outside (a IFrameClock, a machine learning environment, you name it), but we don't want to connect it to every node that needs that context. We invented auto-connect-pins that infect the parent patch and thereby implicitly lead to a new input within the patch. This would also work recursively all the way up in your patch hierarchy so that you'd only need to connect it in the topmost patch, or wherever you want in order to stop infecting patches. There were two ideas how to set the context:

  • connect to the Context input pin from outside - often leading to yet another top-level patch
  • connect it from inside the patch. This is the feature I am talking about: the ability to feed an input pin from the inside, leading to getting rid of the input - making it a local variable.

The feature of being able to feed an input from the inside of a patch basically leads to the same semantics as you laid out:
Within the current frame, you first write into something and somewhere else you can read it back again. The only difference here is

  • how you communicate the feature
  • how the patch communicates what it does

@ScreenDream
Copy link

This is a very interesting topic that plagues every node system:
On one hand, having the links helps a lot with making clear what goes where and what is what, on the other hand, the links themselves get in the way fast, and creating elaborate layouts with them is a pain to maintain.

One idea I had in the past was, to have a kind of a 2.5-D canvas, where you can put cables "in the background" (under the floor, in the wall if you want a metaphor), but make them more prominent with a shortcut. So a kind of "depth" so to say, that still allows you instantly to see where things go.

I always imagined the links to look a bit like holes (bigger empty circles) with the link going into them halfways to suggest the "underground" nature of them.

Or they could be triangles (wich is unused as a symbol in VVVV ATM AFAIK) and could be pointing "outwards" for the "inputs" and inwards for the "outputs" like this:

image

One thing some virtual patching environments use in a musical context is, to make the links fully visible at the ends but fade the center out to something rather subtle. That does not solve the issue completely, but makes it at least less prominent.

Another solution I saw in such environments is to only make the links connected to currently selected nodes fully opaque or highlight them in a specific style.

I personally think that having a way to make visible where things go is important, since like with the current pads, it can be hard to track down where stuff goes otherwise or it needs a search, which is pretty disconnected and awkward/non-visual for a visual language.

Cheers,

Tom

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants