Thinking about this a little more...
If I understand johannes correctly, that new connection is supposed to serve two tasks: A) transmitting references B) Allowing to overwrite execution orders. I wonder if it is clever to use a single connection type for both, as B) imposes restrictions and odd problems for A) that can only be solved by adding additional rules (which is not ideal). Sometimes A) and B) can even be conflicting.
Lets consider a reader/writer relation between objects (like the delayline read/write objects - basically it's a supply/use relation that applies to all object references, like tables, memory, etc.). The reader reads from a writer that's patched on the same net via object instance reference connections. Lets imagine the bool connection in the following screenshots is the proposed object instance reference connection.
In this first patch, the the transmission of the reference from the writer to the reader is simple.
In the second patch, we have two readers reading from the same writer. As they are parallel, it is undefined which one is executed first. But they are always executed after the writer.
If it is important that one reader is executed before the other, we could do this: There is just one writer on the net, so both readers know where to read from.
Lets consider this patch: B) requires each object to have a object instance reference input and an object instance reference output. However, that means we can have two writers on the same net like on this patch here:
How does the reader know which writer to read from? The problem can be resolved by adding a new rule: A reader reads from the writer patched upstream. (but I think additional rules are always uncool and make things more complicated)
Now we come to the next weird case: Here, each reader will find two writers upstream. We will have modify the rule so that each reader reads from the first writer upstream. Now both readers will read from writer2.
If we want to have reader 1 reading from writer 1 and reader 2 reading from writer 2, we have to choose this topology:
Now it is undefined, if reader1 or reader2 is executed first. Reader 1 could even be executed before writer2. As we can see from the last two examples, it is not possible to have all execution orders and still correctly transmit all object references. This is a case, where A) and B) conflict each other.
Also: What would you do, if you want to have the reader executed before its corresponding writer?
I think this can only be solved by separating the reference transmission (A) and the ordering (B) into two different wires. Why would they be on the same wire after all? A) and B) are two very different things. Here's my proposal:
Order wire
Each object has an order input and an order output in its title bar. Order wires are patched bewteen those terminals to define the execution order. Upstream objects are executed first. Order wires can be split (one output can be routed to two inputs) and merged (two outputs can be patched to one single input). That way, all possible execution orders can be realized.
resource wire
A resource wire is a wire like any other (bool, srate frac, krate frac, ...). Objects can have outputs if they define a resource (e.g. a table or a memory block). Objects can have inputs to make use of a resource. Now it is possible to have a single object define or use mutiple resources.
Resource wires (or reference wires if that sounds better) can be split (one output to two inputs) but not merged. Just like all other wires we have right now.
Resource wires don't have a datatype. Internally, a resource wire could simply be the string of the C++ instance defining the resource, just like we have now for tables and delaylines.
hierarchy
The hierarchy that defines the execution order would be like this (lower index = higher priority).
- order wire
- conventional wire (bool int, frac, audio, resource, etc.)
- maybe midi wires?
If 1 is not present, 2 defines the order. And so on.
The final execution order is defined by this rule: An object is executed once all upstream objects are already executed.
