optimization of really large files as carrier tracks

[soulware1]

I'm trying to use this for a #cool effect and using a large audio file just so its more likely to make sense, but i had to cut down hours of audio from it just so it wouldn't fill up all my memory and crash

[Firepal]

Hours?! Just how large was your audio file? I don't know if we need the entire audio data loaded at once (which is the current behavior), but hours of audio may still be a lot of spectral data we need to keep around.

We might be able to get by quantizing it... I don't know this stuff too well, Arden knows the math.

[soulware1]

Hours?! Just how large was your audio file? I don't know if we need the entire audio data loaded at once (which is the current behavior), but hours of audio may still be a lot of spectral data we need to keep around.

We might be able to get by quantizing it... I don't know this stuff too well, Arden knows the math.

last i remember it managed to fill up all of my remaining ram while nothing but the file browser and the terminal opened, and im betting the resting free ram is around 5 gigs

[Firepal]

How much RAM do you have?

[soulware1]

ok the resting state of free ram is actually 14 gigs
(ram is 18 gigs)

[Firepal]

It could be possible to avoid loading the entire audio data in RAM by streaming it instead, but I don't really have a solution for the resulting frequency data that we have to store in RAM for each frame. At least in the current iteration.

I'll put a pin in it