@s.elliot.perez I'd also be interested to see what you came up with, and as far as I can tell I'm not high.

@ingox Nice!

@seb-harmonik.ar Oh I see! I didn't know dsp sort order was influenced by the object creation order. The fact that you can't see it suggests to me that this is one of those behaviors one shouldn't rely on if code clarity is your goal. The creation order can be seen if you open the patch in a text editor, right?

@jancsika said:

You might want to start looking at the source for these questions.

I know, I know.... I can't understand my hesitance.

That's the intended behavior. I thought @jameslo was complaining that his patch froze the GUI indefinitely.

Yeah, while the busy wait is happening, I don't care that the GUI doesn't update. But once it's done I was expecting it would update, and I thought that if there happened to be N busy waits in some message evaluation tree, then the GUI would update after each one, but I don't think that's how GUI updates are scheduled. I rewrote the quicksort to remove the slowMotionInstantReplay and insert a busy wait every time 2 table elements are swapped. It looks like the array display isn't updated until the entire sort completes, whereas I was hoping to see each pair swap sequentially.
quicksort with busy wait.pd
(This isn't really the behavior I reported earlier when I said it "freezes the UI". In that case the table would only be partially sorted, but I haven't taken the time to reproduce it, mostly because I really don't think this approach is right in Pd.)

Edit: yeah, I can see now that I wrote "blocking the UI" previously, but think that might have been the wrong way to describe what I was seeing. Sorry.

@seb-harmonik.ar Ugh, I'm still not following. Could you please post your test patch?

@seb-harmonik.ar I'm confused. You write about manipulating the dsp graph sort order, but you don't mention using the subpatch/audio connection idiom as described in Pd/doc/3.audio.examples/G05.execution.order.pd. Is there another way? Please show!

@Nicolas-Danet Understood, but my point is that if you have to connect two subpatches with an audio connection in order to make s~/r~ behave like an audio connection, then why not just use an audio connection? (I guess they didn't show that American cartoon in France )

I remember a cartoon (Bugs Bunny? Roadrunner?) where they are in the desert with a can of freeze dried water. The instructions were "just add water". If you have to use subpatches connected by audio connections in order to make audio sends and receives latency-free, then what have you gained?

@whale-av more specifically, not counting them

@ingox Automata theory was my favorite topic in college, and both of these examples make me think of big-O notation. Your first one suggests we could have a measure that expresses the fewest number of language tokens required to implement an algorithm, a kind of programming-time efficiency rather than run-time efficiency. The second one (which I only learned about through this forum, and which made me laugh when I first saw it) highlights the fact that big-O assumes that the algorithm only cares about the number of input tokens, not their values.

I hereby grant everyone permission to digress for entertainment's sake. Not that you needed my permission.