thanks, I just checked and I am not sure how to understand the results
- pix_delay 3000 happily goes up to 83% RAM and stays there once the
delay is full
- pix_delay 4000 crashes when the RAM reaches 43%
are there other consumers of memory?
yeah RAM usage is around 38% before opening PD
could it be that pix_delay 4000 requires more RAM than the available BUT it only crashes after a while when the system or PD realises that there is not enough RAM?
Pd doesn't know anything about that.
however, with modern OS, you can overcommit memory, that is, you can ask for more memory than is actually available, and the OS will happily give you a handle to that (non-existant) memory, hoping that by the time you want to use it, some other processes have already released their memory claims. you might well experience this.
you can check the size required to store your image data with roughly: <numframes>*<width>*<height>*<depth> with <depth> being 4 for the typical RGBA pixes (the default on linux and w32) and 2 for YUV (the default on macOS, iirc).
if you don't care about alpha, you could convert the pixes to YUV before sending them to [pix_delay] using the [pix_yuv] object, possibly reducing memory load by 50%.
also, these days i'll usually suggest using [pix_buffer] to build your own delay-line. it allows you fine-grained control over pre-allocation of the images, as well as images of varying size and is generally more flexible.
ok thanks! I will have a look into that