[PD] pix_delay limits

[enrike]

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