Are you saying that in situations where timing is critical a fixed sized array should be used instead of [list] objects? If not, can you give the laymen version for us non-programmers?

Edit; I assume a list created with [pack] would be an example of a list whose number of items are pre-allocated at instantiation time and would be as good as an array in this case?

Yes, that's correct.

Now-- you can run into a situation where you need to manipulate a message that is large enough to be cumbersome for [pack] yet still small enough to process reliably using [list] objects. My point is that the interface of [list] doesn't tell you when you've gone from stack allocation-- which is predictable-- to heap allocation-- which isn't as predictable. It's hard-coded to make the shift at lists greater than 100 elements, but even knowing that it's hard to keep track in a non-trivial chain of objects.

Furthermore, it's not clear to the user which [list] objects actually need to copy lists in the first place. For example-- [list split] does not copy the list. That means that the size of the list doesn't affect the time the object takes to compute its output.

This should all be documented... List operations are fundamental (and, even after a year, the solution I arrived at is not optimal).

Generally, I'd advise you to be cautious about any non-signal class in Pd where you aren't pre-allocating the number of items at object instantiation time.

Even if [list store] were improved so that it doesn't allocate memory on each call, that doesn't improve the worst case performance. And if you are trying to hit soft realtime deadlines with a chain of signal objects, worst case is all you should care about.

Also, notice that the use of alloca in the [list] family objects doesn't help you here because the implementation silently shifts between stack and heap allocation on an arbitrary size boundary. You can hack your way around that as I'm sure most Pd users do, but it's just not a great interface for a realtime environment.

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.

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

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.

I don't remember any problems with this on 2.15.1, and I can successfully create a new array in a patch with 2.15.2.

Side note-- I just got "snap-to-grid" working for the impending release of 2.15.3.

Here's another demo from Zack which shows the handy "Download" feature:

@60hz Thanks. It should be a pretty easy change to one of those options.

@60hz Yeah, that shouldn't be a problem.

The difficulty with [cnv] is it that it has a "selection size" that is independent of the size of the drawn rectangle. Worse, it is the "selection size" and not the drawn rectangle which Pd counts as the bounding box for the rectangle. This means that in Pd Vanilla the drawn rectangle can extend arbitrarily past the bounds of a GOP rectangle, which is just plain bonkers.

I'm talking about the blue square-- the "anchor" you can use to resize it.

Would it improve things if this blue square was always in the corner of the drawn rectangle of [cnv]?

It's easy to make it partly transparent, but it may be better to display it inside the main rectangle so it doesn't get in the way.