Is it possible to do a timed busy wait in Pd?

busyWait.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 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:

1. 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.

2. 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.

@jancsika @jameslo Here is an implementation of this:

busywait.zip

It works, but will freeze the GUI.

Edit: Ah, sorry, just saw that you already did this above...

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.

@jameslo Yes, this is unfortunate.

Another way to approach this, although not really solving the issue, would be to decouple the array the algorithm is operating on from the visual display.

Here i added a second array and the visuals are just performed by pipes: quicksort with delay.pd

So the algorithm is carried out immediately on the first array, but the display on the graphic array is delayed.

@ingox Nice!

A good exercise here might be to consider an approach where [until] could be swapped out with a [metro] or an abstraction around [metro] to get the same interface.

Using [metro] will cause the steps of the loop to be executed by Pd's scheduler. At that point you'll get the GUI updates you're looking for, at any speed you specify for the metronome.