Hey guys, I’m trying out FluCoMa for the first time and have been testing out the creating a 2d corpus explorer tutorial, but when I load large audio files into the patch it freezes my max / ableton until the file is loaded which can take a while, as I want to integrate it into a max for live device I’m worried that this freeze will hurt the user’s experience and I was wondering if there was a way to load audio files without freezing ableton. MuBu seems to handle loading large files in really well and doesn’t freeze but I would like to be able to use flucoma for concatenation synthesis.
The good news is that you can. The bad news is that it is your responsibility.
Let me develop. The audio file loading can be done many many ways since we don’t load audio in FluCoMa, just json. the audio is on you: you can use polybuffers, buffers, and even direct-to-file playback.
I presume you are using our concataudiofiles utility. That is indeed going to take all the files and put them in a single buffer, which is time-consuming. but you can code your own loading process - even use Mubu to load and then export a max buffer
I reckon @rodrigo.constanzo has found ways around that for his sp tools, as he is fan of hugs datasets.
Which part is loading slowly? Specifically audio into buffer~s? Or “the whole process”?
I remember from my testing and optimizations in C-C-Combine that dicts in Max are really, really, slow for large amounts of data. To the point that for the M4L C-C-Combine device I break the corpus data into three parts, the audio, the “data” (as a txt file that will be loaded via coll) and a much smaller dict for metadata stuff. At the time @a.harker also optimized the way that data could be loaded into entrymatcher (what I was using for matching) so loading all the data was “instant” in C-C-Combine.
I don’t remember if I did any significant testing of loading jsons directly into fluid.dataset~ but that’s essentially what I do now. I don’t suspect this to be very slow as you are “read”-ing a file into fluid.dataset~ as opposed to iterating/dumping a file in (as was the case with dict → entrymatcher initially for C-C-Combine).
Now if it is the buffer~ loading that is slow, that’s a different issue. I’ve always just done this in a normal-ish way. Either reading a file into a polybuffer~ or buffer~ depending on the approach I was using. In some cases these files were very big (40min+) or a large amount of individual files (3k+) and that would, unavoidably, pinwheel a bit. Most of the corpora that I’m working with are between 5-20m long (~30-80mb) and these essentially load “instantly”.
Now beyond all that, it is possible that MuBu does optimization in terms of how it loads audio into memory, particularly given it is using it’s own buffer format. I did entertain the idea of using something like ibuffer~ from @a.harker’s externals as it loads audio files in the format that they actually are, whereas Max, by default (as far as I understand) always loads files as 32bit, which can take more memory, and presumably(?) load slower. I only briefly looked into this when I was working with large 4channel audio files that were gobbling up a ton of RAM just by being loaded.
AAAAAND
Lastly, I, personally, think that some pinwheeling is fine when working with large processes/files and to a certain extent is expected. Like, loading Live itself isn’t instant, and the same goes for most plugs. So there’s an expectation of things taking a bit. You can/should obviously try and mitigate unnecessary pinwheeling/waiting though.
I would say the whole process including the buffer. The file was about 40mb and froze for about 40 seconds iirc. Yes I believe it was using dict, your idea of breaking it down seems nice. I will explore your ideas. Thanks Rodrigo!
I developed the 11ffload~ external precisely because of this blocking behavior of Max buffers which is even worse when loading encoded formats like flac for example. It can also convert samplerate while loading which can be useful in flucoma context.
If we could formulate a concise need for it along with scenarios there may be a way to bring such improvements to Cycling '74 for the buffer~ and related family of objects. stretch~ supports async processing, maybe buffer~ could too!
