For a topic on matrix mixers by @lacuna I created a patch with audio paths that included a s~/r~ hop as well as a throw~/catch~ hop, fully expecting each hop to contribute a 1 block delay. To my surprise, there was no delay. It reminded me of another topic where @seb-harmonik.ar had investigated how object creation order affects the tilde object sort order, which in turn determines whether there is a 1 block delay or not. Object creation order even appears to affect the minimum delay you can get with a delay line. So I decided to do a deep dive into a small example to try to understand it.

Here's my test patch: s~r~NoLatency.pd
The s~/r~ hop produces either a 64 sample delay, or none at all, depending on the order that the objects are created. Here's an example that combines both: s~r~DifferingLatencies.pd
That's pretty kooky! On the one hand, it's probably good practice to avoid invisible properties like object creation order to get a particular delay, just as one should avoid using control connection creation order to get a particular execution order and use triggers instead. On the other hand, if you're not considering object creation order, you can't know what delay you will get without measuring it because there's no explicit sort order control. Well...technically there is one and it's described in G05.execution.order, but it defeats the purpose of having a non-local signal connection because it requires a local signal connection. Freeze dried water: just add water.

To reduce the number of cases I had to test, I grouped the objects into 4 subsets and permuted their creation orders:
The order labeled in the diagram has no latency and is one that I just stumbled on, but I wanted to know what part of it is significant, so I tested all 24 permuations. (Methodology note: you can see the object creation order if you open the .pd file in a text editor. The lines that begin with "#X obj" list the objects in the order they were created.)

It appears that any time the phasor group is created before the r~, there is latency. Nothing else matters. Why would that be? To test if it's the whole audio chain feeding s~ that has to be created before, or only certain objects in that group, I took the first permutation with latency and cut/pasted [phasor~ 1] and [*~ 44100] in turn to push the object's creation order to the end. Only pushing [phasor~ 1] creation to the end made the delay go away, so maybe it's because that object is the head of the audio chain?

I also tested a few of these permutations using throw~/catch~ and got the same results. And I looked to see if connection creation order mattered but I couldn't find one that did and gave up after a while because there were too many cases to test.

So here's what I think is going on. Both [r~ next] and [phasor~ 1] are the heads of their respective locally connected audio chains which join at [-~]. Pd has to decide which chain to process first, and I assume that it has to choose the [phasor~ 1] chain in order for the data buffered by [s~ next] to be immediately available to [r~ next]. But why it should choose the [phasor~ 1] chain to go first if it's head is created later seems arbitrary to me. Can anyone confirm these observations and conjectures? Is this behavior documented anywhere? Can I count on this behavior moving forward? If so, what does good coding practice look like, when we want the delay and also when we don't?

@jameslo Oh...!
Downloaded, but it will be a few days before I get enough time to play with that.
This is much the most interesting topic since a while.
Let's hope its a Schrodinger and not a Heisenberg.

It made me recall something in an explanation of [block~].......... d_ugen routines.
And that led me to line 524 here......
https://github.com/pure-data/pure-data/blob/master/src/d_ugen.c

But it will have to wait (more than 1.45mS) and I doubt it will make me any wiser.
David.

IIRC (sorry if i'm wrong).

Building the DSP chain means doing a topological sort to linearize the graph of the DSP objects.

For that all the DSP objects of the topmost patch are collected in reverse order of their creations. Then the first node in the collection that has no DSP entry is fetched. The graph is explored depth-first (outlet by outlet) appending the DSP method/operation of the connected objects to the DSP chain. For that all the inlets of the tested node must have been visited. Otherwise the algorithm stop and fetches the next outlet, or the next object in the collection, and restart the exploration from it. That process is recursively done in subpatches discovered.

Notice that it is not easy to explain (and i don't have it fresh in mind). The stuff in Spaghettis is there. AFAIK it is more or less the same that in Pure Data (linked in previous post).
I can bring details back in my head, if somebody really cares.

.
.
.

You can also watch the beginning of that video of Dave Rowland about Tracktion topological process.
EDIT: The first ten minutes (the rest is not relevant).
WARNING: the way things are done in that talk is NOT how it is done in Pd.
It is just an illustration of the problem needed to be solved!

Introducing Tracktion Graph: A Topological Processing Library for Audio - Dave Rowland - ADC20

.
.
.

@whale-av said:

@jameslo I agree. I did report a bug once, but have never dared ask a question on the list.
The list is the domain of those creating Pd. I often read what they have to say, but I would not dare to show my face.
David.

It is really sad to see experienced users intimidated by developers.
But at the same time i totally understand why (and i still have the same felling).

@Nicolas-Danet This is super helpful, thanks. If you're right about Pd's topological sort (and I'm not doubting you, I'm just taking my cue from your caveats), then it's consistent with the creation order side effects I observed (not including the [lateral~] patch anomaly). It also implies that there must be similar connection order side effects since there is a depth-first traversal of the graph from each tilde object processed. I stumbled across an example while trying to simplify and explore my [lateral~] patch: subpatchSortOrderTest.pd

Either [pd passthru1] or [pd passthru2] will be earlier in the dsp sort order, and so only one direction (1->2 or 2->1) can have zero latency. It doesn't seem to matter which subpatch is created last, and that makes sense because neither are the heads of any local audio chains. But if you disconnect/reconnect either subpatch connection from [*~ 44100], thereby reordering the connection fanout, you can control which direction has zero latency. (Edit: the subpatch with the input audio connection created last is run first)

But regarding "DSP objects of the topmost patch are collected in reverse order of their creation", this is just an arbitrary choice, right? I think Pd could have started with the first DSP object created and its topological sort would still work.

Yep it is arbitrary, just an implementation detail ; It is collected in a linked-list queue, and it is more efficient to prepend that to append to. I had a look into Pure Data sources, and it appears that it hasn't changed since.

Anyway it is interesting to understand what's hap, but nothing should rely onto it. It could change (but i doubt it will).

@Nicolas-Danet said:

Anyway it is interesting to understand what's hap, but nothing should rely onto it.

I agree with this in principle, but here's the thing: there's no mechanism other than using a local audio connection between subpatches or abstractions to control the sort order of a non-local audio connection. So I have to choose between cluttering up my patch with a spider's web of connections, or I have to roll the dice and see what kind of latency I get. And heaven forbid I have to edit that patch once I get it working, because simply cutting and repasting could change its behavior.

I'm exaggerating for effect, but I think my point still stands.

That's a pitty that no mechanism (native) is available to ensure order in those cases.
I have no idea how it could be done ; but that's a valid request.
There is a lot of workarounds in that forum to make things (laboriously) that should be done at the core level (simply).
And more workarounds (= less encapsulation) means a core harder to change compatibilly.
For now IMHO you should continue with spider's web, and ask the devs to implement an ordering feature...
...with almost no chance to be done before many years!

@jameslo
Yes.
Horrible.
Any cut and paste makes changes and in an only slightly complex patch like your cloneException example it would probably take days of trial and error to get the result you need......
.......... and then you could not rely on it when you want to use it as part of a larger patch.
David.

@whale-av To be fair, cut and repaste would only affect the heads of audio chain tributaries and fully independent audio chains (and also certain audio fanout connections), so it's not like there are landmines everywhere. Also, in the case of clone, unless you're sending signal between siblings you'll probably never be affected by the different sort order. I'm currently searching through all of my Pd code to see how many times I've fallen victim, I'll report back with my results.

Speaking of clone, I was able to reproduce the clone tilde object sort order reversal using [tabsend~] in an abstraction, which is way simpler (and hence more convincing as a test) than the tortured way I was trying to pass signal laterally. Each instance of [tabsender] sends a different constant to array1. The last instance to run "wins", i.e. overwrites whatever the first one wrote. In the clone version, the 2nd one wins; in the manual version, the 1st wins. So yes, clone seems to reverse Pd's normal tilde object sort order. tabsender.zip

I searched through many of the s~/r~ throw~/catch~ hops in my own code for mistakes based on what I've learned, and it looks like ~50% of all my non-local audio connections carry modulation signals that originate from control rate objects, so those aren't affected much. Only a few programs would have been broken had the non-local connections not matched, but because things were created in signal-flow order where it mattered, there was a consistent (and often unnecessary) 1 block delay everywhere. Many of those patches were later converted to use tabsend~/tabreceive~ under a small block size, and a few were converted to use delay lines. I was burned by the creation order side effect of delwrite~/delread~ once, but it wouldn't have happened had I not taken a lazy shortcut. Hilariously, I also found one test patch that I used to declare definitively, once and for all, that s~/r~ always introduces a 1 block delay if the sort order isn't controlled using the G05 technique. To paraphrase Agent K in the movie Men in Black, imagine what I'll "know" tomorrow!

So as a practical issue, I doubt coders are getting tripped up by this frequently. If you're like me you tend to code in signal flow order, and so you are mostly just introducing latency unnecessarily. RE advice, I agree with @Nicolas-Danet: use local audio connections wherever it matters and never mind the clutter. Even my worst spider web isn't so bad. Subpatches and abstractions can help hide the mess.

But when things are broken and showtime is looming, you'd be foolish not to use what you know, especially when you can always go back after curtain calls and adjust things to satisfy the style police. Here is a summary of the sort rules as best as I've been able to figure them out so far:

• A patch orders its constituent audio subpatches and abstractions, but has no influence over their internal ordering. Consequently, these rules are applied starting at the top level patch and recurse into each subpatch and abstraction.
• Audio chain tributaries and independent audio chains are executed in reverse order of their head's creation, except for those created by [clone], which are executed in the order of their creation (i.e. ascending clone index order).
• Audio branches that start from fanout connections are executed in reverse order of their start connection's creation.
• Whenever the rules conflict, the rule that places the tilde object the latest in line takes precidence.

These sort rules can affect your patch because unless s~ and throw~ buffer their data before their corresponding r~ and catch~ are executed, the latter will have to wait a block to access it. Delread~ will have a minimum 1 block delay.

Finally, I thought of this technique if you're absolutely certain you are going to get burned (or are just paranoid): wrap all s~, r~, throw~, catch~, delwrite~, delread~, and audio chain heads in their own subpatches. I noticed that if you modify the contents of a subpatch, it doesn't change its sort order in the containing patch, so you can add test code (e.g. [sig~ <uniqueNr>]->[tabsend~ <sharedArray>]) to subpatch pairs and check their execution order without changing it. If the order is wrong, then you cut and repaste the appropriate subpatches or audio connections according to the rules above until it isn't. That should take 15 mins, not days.