Open gregsn opened 1 year ago
The visualization should be like this:
For those guys that have no incoming links:
For those guys that have incoming links:
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 #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?
Idea
A
Pin
orVar
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:
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 aPad
/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
IsAvoiding 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 oneValue
pin to the other, making sure that the writing part in your patch is executed before the reading parts get executed.UX / Feel / Workflows
Value
input, read from it and write back to aValue
outputOpen questions
Encoding
Pros and Cons
Pros:
Cons:
Value
must have the same type as Output namedValue
. This is a breaking change.