was this fix ever implemented in a repo somewhere?
my project has three samples that are fairly short (for me): 10 seconds, 37 sec, 54 sec. there’s no indicator that they’ve all finished loading, or how much RAM they take up (at 48khz/32bit stereo), but i definitely noticed the buffer overrun. when only one track is playing, the audio will unpredictably jump to different parts of the other two samples.
is there an easy way to keep track of RAM usage on the sample load screen, or should i follow a temporary workaround for sample size? i.e. “for now, keep all samples under X seconds long.”
for comparison, the er301 displays total memory used on its sample load/clear screen, and won’t proceed if asked to load a sample that exceeds available RAM.
i poked through the lua code, and i’m guessing that somewhere around here, i might try adding a function to display available RAM: free -h | awk '/Mem:/ {print $4}' via something like m.sys.ram, though the displayed number might only be useful in the context of how much of that can actually be used by mlr’s buffer(s). it doesn’t seem to fit in the toplevel system screen, as the existing status info lines up neatly with the left-side options.
maybe it would still be worth adding this free RAM info to an mlr status screen somewhere; perhaps the clip select page? otherwise, there’s no indication of why mlr starts behaving erratically–if it’s norns itself or mlr.
