Connections?

I have two kinds of components: StateComps and SegmentComps

StateComps an be wired into other StateComps directly or via SegmentComps (stateA > stateC or sStateA > Segment1 > stateB)
And a connection can be created via select ops (stateA — selectOp(selectstateA/out1 somewhere) > segment2 > stateD)
The attached file shows the possible connections.

states.2.toe (2.12 KB)
When playing back the file, I start at some state (stateA), and on click on a button, I need to go to the next state connected to this one. The problem is how to dynamically find out to which state the current state is connected. In the attached example I can go from stateA to:
stateB (via Segment1)
stateC
stateD (via select , Segment2)

Ideally, I’d like to create a setup where I don’t need to run a script to gather all connection information before playback. So creating/renaming/rewiring states (segments) should automatically make the new connection paths available.

Any ideas how to achieve this?

Thanks
Achim

Hey Achim,

maybe the attached will help. It’s a DAT Network that get’s you the connections for all the nodes. Now you have a Table you might be able to work with. when reconnecting just force cook the eval dat and you get a fresh reference table… ultimatly you will still have to run a script that goes through the table… But you want a table that lists the path correct? I keep trying a little :slight_smile:

cheers
markus
project1.tox (1.52 KB)

Ok,

with this new version you get the path in a table… But I can’t do branching - for that I would have to use tabfinds and counters - i believe - which is a little bulky in a dat network…

cheers
markus
project1.tox (1.84 KB)

thanks a lot for the files markus. It gave me some ideas.

Yes, there’s a script which chooses one of the possible connections form the “master table” and then sets up another component which plays those states/segments. Till now I have an IN/OUT table in each state and segment component, so maybe your idea of a master table is the way to go (will save a couple hundrets of ops). Unfornuatly I still need to use a scipt to gather the connections and store them in that table, because:

In your file I need to run the lc command every time I create/delete a new state/Segment
and I think you locked the lc output and manually deleted some rows, so I need to do this as well each time a state is added

It’s been some days since I looked at your file, but I think it didn’t handle the stateA > stateD (via select DAT, Segment2) correctly.

Also, the segment connections need to be “ordered”, meaning segments have a “default segment” parameter and those where it’s
1 should be in the top row of the connection table which is probably difficult in DATs

And all these states and segments don’t live in a single container, there are hundrets of them bundled in various containers (called sequences) and these are interconnected as well…

I’ll have another look at your files next week
Thanks again
Achim

yeah - there are a couple things in my file - when reconnecting containers you still would have to recook the eval1 DAT.
The convert1 is locked because all the DAT nodes had to be removed - it should be easy though to get around this by proper naming.

Still my approach has a major shortcoming which is multiple branches - no reasonable idea how I could solve this.

But then I thought couldn’t you have a script in each of your Segments and States that reports back to a main script once it gets (re)connected? you basically only would need to know the path of the previous node… What would be needed to do this efficiently would be a “on node cook” option for the text DAT - but for now the info CHOP should do the job.

cheers
markus

So each state could output a DAT table holding the state’s path variable. Then each state has info about it’s incoming states. Fine, but I also need info about the next reachable state. To get this I would (in a text DAT monitoring the in DAT) loop over all rows in the in DAT (holding the paths to the states connected) and use the table command to write the current state’s path in an OUTSTATES table of all the incoming states.

But this will fail if I delete a state. This deleted state will live in the other states OUTSTATES table forever. Only way I see to fix this would be a pre-delete script, which would loop over the in DAT of the “to be deleted state” and remove the current state from each connected state’s OUTSTATES table.

And basically the same problem arises if I unwire a state. I also would need to remove the “unwired state” from the OUSTATES table of the connected states, but the connection info in the in DAT (holding the paths to the connected states) is already lost, as I unwired it.

Makes sense? it’s hard to explain
Achim

Found a way. Should work great when todays renaming and in DAT bugs are fixed, but it has a major drawback:
I need 10 nodes per state/segment to define the logic. I know touch can handle an unlimited number of nodes, but this will quickly accumulate to 10000+ additional nodes (just for describing the logic) and will increase file load times.

So maybe you or someone else has an idea how to reduce the opcount.

The general idea is to have two outputs per state.
Chaining states using the first in-/ output will define the default sequence, appending a column per connected state
All alternative targets a state can reach (defined via the second in-/ output) are stored in additional rows below the current states column as can be seen in the FORPLAYBACK table.

If you increase the PlayBackIndex CHOP, the
defNEXT CHOP shows the next state reachable by default
alternativeNEXT shows all alernatively reachable states

datcon.28.toe (3.89 KB)

Hope the description and node comments help understanding the network and that someone has an idea how to reduce the necessary nodes

Thanks again
Achim

And it has another drawback. As other states reachable from the currect state are added to the table when processing the reachable (downstream) states, I need to connect all states in one long (uninterupted) chain, which will cause quite some cooking when having 1000+ states (with 10 nodes per state).

Hey Achim,

that’s funny - we almost had the same approach here, except I’m using 1 input and 1 output reducing the nodes in each stage to 7… It is different though and the output gives you three tables with the last column always being the current stages it’s alternate possibilities…

I hope I didn’t miss anything and by that limited the functionality…
Maybe it’s another clue for your puzzle.

cheers
markus
connections.tox (2.01 KB)

Thank you again markus,

I can’t figure out which connections to use after selecting an alternate route. For example, index == 0, I’m at segment 1and from there I can reach segment2 or segment5 (last col of sort3). I use this column in my UI to provide a way to select the next segment. Now I decide to go to segment 5. I increase index CHOP to 1 and now last col of sort 3 gives me the new reachable segments, but the list also includes the segments reachable if I was at segment 2. So how can I filter these out in your setup? Seems like I’ve been spending so much time on this that I can’t figure out this possibly simple stuff.

The second problem is visible if you have a look at the attached file (same as yours but with an additional state at the end of the chain (named “end”))
connections.2.toe (3.55 KB)If you set the CHOP index to 3 (we are at segment 9 if following the default route (row 0)) then the last column in sort3 does not feature the new “end” segment I created (in row 0 that is). I guess this is what you tried to fix with the last eval DAT (shifting columns to the left if previous is empty), but it only shifts one column.

Finally, this approach gets very slow. I stuffed above example in a container (with in/out ops) and duplicated/wired this 5 times. Now it takes ~5 seconds when changing/renaming segments and the final table DAT gets really big.

Cheers,
Achim

@markus: Reply to your file on previous page

So I’ve been thinking about a general purpose RFE which would help here but which is not only applicable to this situation, here an idea I’d like to discuss:
How about a new type of (logic) in/out/select ops, which provide a “two way/reverse” info about the connected components.

A logicOut op would have internal data holding the paths to all connected (outgoing) logicIn ops. If the connected logicIn op is itself connected to a logicOut op, then it traverse the connections to the next logicIn op, appending the found paths…

A logicIn op would have internal data holding the paths to all connected (incoming) logicOut ops. If the connected logicOut op has a logicIn op connected, it will traverse the connections to the next logicOut op, appending the found paths…

A logicSelect op can select one of the above logic in/out types and just passes the info through.

Again, I’m not sure how useful this could be for other scenarios, so before posting this as an RFE I wanted to see if someone else could imagine something like this being useful.

Achim