[Proposal] Introduce Pin / Var - replacing Inputs and Outputs in most cases

[gregsn]

Idea

A Pin or Var is a versatile patch element that can represent local variables, inputs, and outputs.
You can create it similar to how you create Inputs and Outputs - via the node browser:

If the concept works out, Input and Output choices could possibly vanish from the node browser.

this would solve quest #50.

Cases

There are four cases we have to consider:

• no ingoing, no outgoing links
• ongoing link, no outgoing links
• no ingoing link, outgoing links
• ingoing link, outgoing links

And we need to consider many of them with the same name.

Concept

The main idea is that a Pin / Var holds a transient reference to an object, while a Pad / Property holds a presistent reference to an object.

An object can flow into the patch from outside, can be referred to, a new object reference can be assigned to it several times and it can finally flow outof the patch.

The hope would be that we can infer the existence of Input and Output pins via its usage.

Simple Case: Let's look at one isolated Pin only for now.

Input pin:

If there is no ingoing link the value has to be fed from the outside. We get an input pin. If we feed the pin from inside the patch, we get no input pin.

Output pin:

If we write to a Pin (ingoing link), it potentially makes sense to create an output for it.
Pin Is

• Visible if there is no outgoing link on the Pin
• Optional or Disabled if there are downstream links

Avoiding ugly links by referring to the same local Variable several places in the patch

Let's say the user places many of those with the name Value.
Some of them are connected downstream. One of them is connected upstream.
Semantically this would be like hidden links going from the one Value pin to the other, making sure that the writing part in your patch is executed before the reading parts get executed.

UX / Feel / Workflows

• After creating a Pin / Var we either get a generic potentially unused input or none at all, as it is not in use yet.
• write to it to get an output
• read from it to get (or keep) an input
• do both and you will not have an input nor an output (however the output could be optional)
• create another one to refer to the same variable
• read from & write to as many as you want
• only the ones that are not connected upstream will have an ambiguity warning if there are many others that are written to
• we can have a Value input, read from it and write back to a Value output

Open questions

• Do we allow several with Pins with ingoing links? It would be a nice to have, however which of those are the reading ones referring to?
• Maybe we can say: always the last one written to or always the first one
• Maybe we have ambiguity warnings on the receiving/reading ones

Encoding

• It would be nice to have a central place where to store some users choices (comparable to the Slot/Property idea, where several Pads refer to one such thing)
  • Whether or not an output exists and what's its visibility
  • Whether or not we want to have warnings?
  • Maybe we even can easily decide Input / Output for use cases in interfaces, where we don't have links and want to overrule any system that infers the existence of input / output.

Pros and Cons

Pros:

• We have one element that is versatile and allows us to refactor a patch with many inputs into one where we feed all patch inputs with one object from within the patch. We don't need to replace all the inputs with Var-Readers and place some Var-Writer somewhere else.
• The other way around: As soon as we don't feed the object from within the patch, we get an input for it.
• Writing into a Pin / Var automatically gives us a meaningful output. But we can disable it if we need to.

Cons:

• existing Input and Output elements need to get converted
• Var referred to by many Pin elements needs to get introduced. With configuration options. UX needs to get specified in detail
• Input named Value must have the same type as Output named Value. This is a breaking change.

[gregsn]

The visualization should be like this:

For those guys that have no incoming links:

• if an input has been introduced and this guy actually reads this initial incoming value, it should look like an input pin
• if we read a Var written to by the patch earlier, we should see a diamond (the icon known by accumulators).

For those guys that have incoming links:

• show diamond if the Var gets read somewhere else
• show Output if this value gets fed to an output (last one writing)
• show both if both are true

Accumulators on If and Loops can be seen as Vars attached to the regions (with limited scope).

---

I can come up with a weird case. Not sure if this is a no-go:

upper Value is connected downstream
lower Value is connected upstream

• case A) if the lower one depends on the upper one the system would probably create an input for the first and an output for the second (that's the only way to make sense of this patch. Or should we get an error? why?)
  vis box -> box

• case B) if the lower one doesn't depend on the upper one, the system should execute the writing part first and execute the reading part second (in order to actually solve quest [Quest/Proposal] Local variables aka invisible links #50).
  vis diamond on the upper, diamond on the lower

The visualization helps me to understand that this patch does something completely different. However, the magic, sudden switch between behaviors depending on the deletion of a link somewhere inside the patch sounds like a no-go.

So case A) is forbidden then?? I can't connect from Value "input" to Value "output"? Do we still need dedicated inputs and outputs for those cases? (thus also allowing them to be of different type)

Is this proposal an addition then?