Can Pd busy wait?
Is it possible to do a timed busy wait in Pd?
This hangs my machine for a while, then sometimes reports nonsense like what's shown. Seems like [until] blocks everything else from running, including the UI and [delay]. I've tried alternating between some finite number of [until] iterations and the value test, but I get similar behavior.
@jameslo Looks like you are trying to spin.
You can reject data during a [delay] with [spigot]...... and delay data with [pipe].
So do you really want to block the cpu?
David.
@whale-av Yeah...I have a recursive algorithm that relies on Pd's evaluation order, and it breaks when I replace [until] with [metro]. I know it's possible to factor that dependency out, but that's a whole redesign when I just wanted to slow things down enough so I could watch it step and get a feel for what it's doing. And yes, "spinning" is the other name for it.
@jameslo You could pack your incoming data into a list...... [list append] or [add2 $1(...... and then [drip] it..... a zexy external.
For Vanilla list-abs has an abstraction to do the same but it needs a metro unless you just bang it manually as required.
Or write an [array] and then [metro] play it or bang a counter.
David.
@whale-av Yeah, I was thinking of something similar: snapshot the input data, run the algorithm at full speed, queue up the sequence of states, then play them back. That fits better into the Pd programming model. But it's interesting that it's not immediately obvious how to make a busy wait, if it's even possible at all.
@jameslo. The [wait] object lets threads be executed after a cumulative waiting time.
It doesn't make Pd busy wait, so the object has to be put in every thread that should be effected:
As you can see in the demo, the bang runs right through to the end, but the bangs after the [wait] objects bang with a delay. The the third time is cumulative, as [realtime] is reset without wait.
[wait] also let through floats, symbols and lists, not only bangs. 
@ingox Good stuff--it's cool when abstractions just take care of the dull bookkeeping for you. In a past life I used to do that kind of thing in Java/c# using static class variables.
The slow motion instant replay approach turned out to be much easier than I anticipated, but I thought I'd post my code anyway to show why a busy wait, were it as simple as in Arduino, would have taken almost no time at all.
Had I been able to replace that [send] with a 300 mS busy wait, I would have been done.
Update: Ha ha, it looks like if the evaluation tree gets too deep you run out of Pd stack. Or I have a bug somewhere. This input data breaks the sort on my machine: quicksort stack overflow input.pd
Update 2: the answer is here. The way I'm performing the outer loop in [pd partition] is bad. Replace it with [until] and it works. It also means that I should replace the quicksort recursion with iteration too--which in turn moots my entire topic because then the need for busy waits goes away. Never mind! quicksort hoare.pd
Update 3: BS alert--I don't know why I thought the topic was mooted by having everything as iteration. It's not. [Never mind( -> [pow 2]
@jameslo Probably.... maybe.... https://forum.pdpatchrepo.info/topic/13125/batch-processing-audio-faster-than-realtime/2
David.
@whale-av I'm not getting the behavior you and @oid are reporting in the topic you linked, but maybe I'm not understanding it. DSP is off:
busyWait with fast-forward.pd
That said, I discovered a few weeks ago that there is a way to make a busy wait using [realtime], but it freezes the UI, which renders it useless in my original context (which no one appears to understand (which is fine because it's probably a dumb idea in Pd anyway ))
busyWait with realtime.pd
@jameslo You need to send fast-forward 0 after you send fast-forward 1000 but this also does halt the UI and it turns out it can not be done automatically, things will just continue on if you use a [t b b] to send the two messages, even if you add a delay to fast-forward 0, which I guess makes sense. I did not test that. I think any busy wait will tie up the UI, pd sacrifices the UI to make sure processing continues so if you try to make it wait by keeping it busy, no UI.
I think the issue we have with understanding your desire to busy wait is why not just design the patch to be able to be paused and pause it when you need to wait, is there something in pd which can not be paused?
@oid Yeah, I'm not saying it's impossible to get the result I want some other way (in fact, I did just that in my quicksort demo above using slowMotionInstantReplay). I was just observing that were a busy wait possible (without blocking the UI), I could have done it with minimum change to my code by inserting one at the point I indicated. But again, I'm not advocating that Pd should support something like that. I'm just discovering what this interesting programming paradigm does and doesn't do well.
@jameslo I know it is not even contributing to the topic and it is really cool that you implemented quicksort in Pd, but here is a quickly made array sort that has nothing to do with anything otherwise:
This is the selection sort algorithm that is not particularly efficient, unfortunately.
Also, here is sleepsort for array: arraysleepsort.pd. Based on https://forum.pdpatchrepo.info/topic/12455/sleepsort.
@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.
@jameslo Are you talking about the big-Orange that cares only about counting the number of tokens?
@whale-av more specifically, not counting them
@jameslo There will be a solution for that..... maybe in S.C. as it's unlikely Pd users will be asked for a patch.
@jameslo Yes, sleepsort is the most efficient sort algorithm, it only needs n operations to get the job done, so O(n) maybe.
Seems like [until] blocks everything else from running, including the UI and [delay].
You might want to start looking at the source for these questions.
In general, you can grep the source for the object name in quotes, like grep \"until\" pd/src/* to find the constructor. Then the rest of the class methods will usually be above that.
In this case it is until_bang which has a simple iterative loop that sends out the bang messages to the outlet of [until]. If you trace the next two calls from the loop you'll see that neither of them-- the generic outlet handler nor the bang method handler-- advance time. So the callback for [delay 1000] never happens because you're just stuck in an infinite loop.
If you want to use [until] for your purposes, off the top of my head I can think of two possibilities:
Put a counter below which breaks when it hits a certain value. Downside is you are now measuring the number of messages passed instead of time.
Put a [realtime] down below [until] and use it to measure the wall clock elapsed time between each bang of [until]. Accumulate those elapsed times until you hit your specified time.
It works, but will freeze the GUI.
It will freeze the GUI only until the right inlet of until receives a bang, right?
That's the intended behavior. I thought @jameslo was complaining that his patch froze the GUI indefinitely.
If not, it seems the question is, "how do I get an object to block the event loop while event loop continues to compute messages from the GUI and clock callbacks?" That simply isn't possible. And I don't think the language-- ascetic as it is-- warrants something equivalent to web workers (which AFAICT are generally running complex C/C++ code transpiled to webassembly).
@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.
Oops! Looks like something went wrong!
