@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.