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

arraysort.pd

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:

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.