Wondering because I could also imagine that subpatches or abstractions could reduce the scope of the DSP design that has to be analyzed at any moment.

That is, if I'm in a subpatch and I make or delete a DSP connection, in theory it could just re-sort the DSP defined within the subpatch, but internally it might just redo everything anyway.

Purely a matter of curiosity. I don't have a concrete use case.

Thanks,
hjh

Maybe the answer is in this video of Millers classes at 1:04:00

OK, will have a look, thanks!

hjh

@ddw_music If Pd's topological sort algorithm were smart enough to know when a change inside an abstraction did not change the sort outside the abstraction, then it would be an easy lift for it to detect that feedback to some abstraction (e.g. one with an [inlet~], an [outlet~], and no connections) does not produce a cycle. But the last I checked, that was not the case, so I would bet that when anything changes, the whole directed graph is resorted.

I guess the issue, then, is, if all the tilde objects get lifted into one flat list, then a change inside a subcanvas could get inserted in the midst of objects outside the canvas. In that case, it probably is necessary to walk the entire tree.

In the video, he starts off the sorting section by saying that canvases tell the DSP layer what has changed locally within the canvas, but then discusses the sorting flow when DSP gets turned on (which obviously has to start at the topmost canvas).

And then in g_canvas.c there are comments like

        /* create a new "DSP graph" object to use in sorting this canvas.
        If we aren't toplevel, there are already other dspcontexts around. */

so the data structure does seem to be split up by canvases.

It's not a crucial point -- just that, I'm expending a paper and wanted to contrast SC's per-SynthDef graph sorting vs Pd's seemingly global sorting. I'd rather not make a false claim.

Mailing list, I guess.

hjh

hjh

@whale-av My issue is (was?) that there are things that affect the DSP sort order that you can't see from the graphics alone. As far as I understand, that's different from @ddw_music's question, which is "how much of the DSP graph does Pd have to resort when there's a change"? That said, I don't understand the reason that @spacechild1 gave on the mailing list--I'd love to see an example.

Well, here's what he said: "The issue is that DSP objects can be 'connected' by other means. Take the delay objects, for example. Some of these objects need to be aware of the order of execution within the DSP graph. Others will affect other objects, e.g. automatically changing the channel count. Pd itself doesn't know what a particular ugen is doing, so the only thing it can do is rebuild the whole graph."

@whale-av Yes, I'm writing a paper, but the paper isn't about Pd graph sorting -- this is a side point -- the latency thread is interesting but would be way too much detail for basically a footnote.

hjh