Finally posted video from my electronic ensemble class's concert last June. Pd didn't figure into the audio side, but 2 out of 3 pieces used Gem for the graphical backdrop.

It was a fun night, hope you enjoy!

Link goes directly to the third piece; the playlist includes the other two.

hjh

Here's a short clip of an interactive installation piece (I guess more of a prototype?) that was shown last weekend.

• Audio: SuperCollider (+ VSTPlugin for the piano and guzheng)
• Graphics: Pure Data + Gem
• UI: Open Stage Control (with heavy CSS gradient abuse -- iPad batteries really don't like rendering 13-14 new gradients, 9 times per second)

Musical decisions are made by flipping bits in a 40-bit word, and mapping various segments of the bits onto sequencing parameters.

At some point, I'd like to do an explainer video, but not today.

hjh

Ahem.

lol

hjh

@jameslo said:

@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

Per spacechild1 on the mailing list: Yes, it does sort all dsp objects in all canvases, every time (because they may have invisible connections, like delay objects or send~ / receive~ / throw~ / catch~).

hjh

@jameslo said:

@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

@lacuna said:

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

OK, will have a look, thanks!

hjh

I always had the impression that Pd reschedules and re-sorts all DSP objects in the system globally whenever a change is made... is that true?

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

@jameslo said:

FYI, an algorithm I was taught in school uses a heap-based priority queue for that B array.

Oh nice, I overlooked that one... the limitations of having zero formal training in CS. I actually have a pure vanilla float-heap abstraction already (https://github.com/jamshark70/hjh-abs)... lower values to the top. For descending order, I'd just negate on the way in and out.

hjh

@lacuna said:

Still I don't understand your idea of building a list without rescanning the array or list for each peak?

Sure. To trace it through, let's take a source array A = [3, 5, 2, 4, 1] and we'll collect 3 max values into target array B.

The [array max] algorithm does 3 outer loops; each inner loop touches 5 items. If m = source array size and n = output size, it's O(m*n). Worst case cannot do better than 15 iterations (and best case will also do 15!).

My suggestion was to loop over the input (5 outer loops):

1. Outer loop i = 0, item = 3.
   • B is empty, so just add the item.
   • B = [3].
2. Outer loop i = 1, item = 5.
   • Scan backward from the end of B to find the smallest B value > item.
     • j = B size - 1 = 0, B item = 3, keep going.
     • j = j - 1 = -1, reached the end, so we know the new item goes at the head.
   • Slide the B items down, from the end to j+1.
     • k = B size - 1 = 0, move B[0] to B[1].
     • k = k - 1 = -1, stop.
   • Now you have B = [3, 3].
   • Put the new item in at j+1: now B = [5, 3].
3. Outer loop i = 2, item = 2.
   • Scan backward from the end of B to find the smallest B value > item.
     • j = B size - 1 = 1, B item = 3, found it!
   • There's nothing to slide (j+1 is 2, past array end), so skip this step.
   • B hasn't reached the requested size, so just add the item.
   • Now B = [5, 3, 2].
4. Outer loop i = 3, item = 4.
   • Scan backward from the end of B to find the smallest B value > item.
     • j = B size - 1 = 2, B item = 2, keep going.
     • j = j - 1 = 1, B item = 3, keep going.
     • j = j - 1 = 0, B item = 5, found it!
   • Slide the B items down, from the end to j+1.
     • Now B is full, so start with second-to-last, not the last.
     • k = size - 2 = 1, move B[1] to B[2]: [5, 3, 3].
     • k = k - 1 = 0, this item shouldn't move (k == j), so, stop.
   • Put the new item in at j+1: now B = [5, 4, 3].
5. Outer loop i = 4, item = 1.
   • Scan backward from the end of B to find the smallest B value > item.
     • j = size - 1 = 1, B item = 3.
     • B is full, and B's smallest item > source item, so there is nothing to do.

Finished, with B = [5, 4, 3] = correct.

This looks more complicated, but it reduces the total number of iterations by exiting the inner loop early when possible. If you have a larger input array, and you're asking for 3 peak values, the inner loop might have to scan all 3, but it might be able to stop after 2 or 1. Assuming those are equally distributed, it's (3+3+3) / 3 = 3 in the original approach, vs (3+2+1) / 3 = 2 here (for larger output sizes, this average will approach n/2). But there are additional savings: as you get closer to the end, the B array will be biased toward higher values. Assuming the A values are linearly randomly distributed, the longer it runs, the greater the probability that an inner loop will find that its item isn't big enough to be added, and just bail out on the first test, or upon an item closer to the end of B: either no, or a lot less, work to do.

The worst case, then, would be that every item is a new peak: a sorted input array. In fact, that does negate the efficiency gains:

a = Array.fill(100000, { |i| i });
-> [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, ... ]

// [array-maxx] approach
bench { f.(a).postln };
time to run: 4.2533088680002 seconds.

// my approach, using a primitive for the "slide" bit
bench { g.(a).postln };
time to run: 3.8446869439999 seconds.

// my approach, using SC loops for the "slide" bit
bench { h.(a).postln };
time to run: 7.6887966190002 seconds.

In this worst case, each inner loop has to scan through the entire B array twice: once to find that the new item should go at the head, and once again to slide all of the items down. So I'd have guessed about 2x worse performance than the original approach -- which is roughly what I get. The insert primitive helps (2nd test) -- but the randomly-ordered input array must cause many, many entire inner loops to be skipped, to get that 2 orders of magnitude improvement.

BUT it looks like Pd's message passing carries a lot of overhead, such that it's better to scan the entire input array repeatedly because that scan is done in C. (Or, my patch has a bug and it isn't breaking the loops early? But no way do I have time to try to figure that out.)

hjh