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
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
