vvvv / VL-Language

The official repo for the design of the VL programming language
31 stars 0 forks source link

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

Open tebjan opened 2 years ago

tebjan commented 2 years ago

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 commented 2 years ago

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:

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

ScreenDream commented 7 months ago

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