@LokiClock said:

A bad conclusion from underisolation. Like a memory leak, the bug shows up somewhere completely different from the source.

So, what's the bug, then?

If outlet order took precedence, the programs could be equivalent. PD is weak on redundancy, which makes it difficult to build conceptually or quickly. And when you expect that redundancy, it ends up looking like all kinds of other bugs. So I mistook the problem again, thinking if you weaved the execution order a little, even if it still came out in right to left execution, it could desync with itself during that weaving.

Execution order is probably one of the most consistent things in Pd. There is a standard protocol for outlet order in that if they are all to be output "at the same time", they would actually output from right-to-left. But sometimes outlets are independent and shouldn't be output at the same time, so it is up to the user/developer to get the execution order right if it matters.

@Maelstorm said:

So, what's the bug, then?

The bug is, if you don't sync on all inlets of all the patches going in, and all the outlets, it looks like you get the right list of outputs, but on further inspection you get the unsynced outlet double, first with the old list and only its spot in the list changed, then with the new data.

And the error is that the information going to all outlets can't also be the trigger of the later ones if it's to reach the earliest outlet first. In the narrow scope it sends the information earliest to latest, so it appears the outlets should execute in the right order, but in the broad scope the earliest is only executed after that information triggers the later outlets.

Basically, the problem stems from the double semantics of t f f for splitting information and for controlling order of operations. Because it's on the trigger inlet, the program has to be analyzed at multiple scales to detect the problem.

Execution order is probably one of the most consistent things in Pd. There is a standard protocol for outlet order in that if they are all to be output "at the same time", they would actually output from right-to-left. But sometimes outlets are independent and shouldn't be output at the same time, so it is up to the user/developer to get the execution order right if it matters.

Right. This would only be for outlets in the same. I'm working on a clearer model of the problem. Since writing above, it seems like one solution is a dummy splitter, or some narrower-scale splitter, which will only control order of operations as far as satisfying one patch's cold-before-hot requirements.

@LokiClock said:

The bug is, if you don't sync on all inlets of all the patches going in, and all the outlets, it looks like you get the right list of outputs...

They key word here is "you". This is a user error, not a Pd bug. It's up to you to make sure things are executed in the order you intend.

Basically, the problem stems from the double semantics of t f f for splitting information and for controlling order of operations.

[t ] doesn't split anything. It just outputs the incoming message multiple times in right-to-left order (as well as possibly changing the message, such as in [t b f], but that doesn't seem relevant here). In other words, it's just meant for controlling order of operation.

Right. This would only be for outlets in the same. I'm working on a clearer model of the problem.

Clearer? Maybe I'm just too entrenched in the way Pd works, but you're actually just confusing the hell out of me. To be completely honest, I'm getting the impression that you're expecting Pd to do something it doesn't claim to do.

Since writing above, it seems like one solution is a dummy splitter, or some narrower-scale splitter, which will only control order of operations as far as satisfying one patch's cold-before-hot requirements.

That sounds like what [t ] is meant to do.