Dynamic buffer loading using poly~
Hi everyone,
I'm looking to dynamically load sounds into a buffer using poly~ during a live performance. I don't want to use polybuffer~ because I want several hundred sounds to be accessible, but as they last between 30sec and 10min each, the total is about ~30GB.
The thing is that I use a coll to know whether a sample is already in one of the instances. When an instance is free, it gets the sample ID I want to play, write in a coll that this sample is loaded (I just add 0 to the entry to close a gate for the next time this number is seen). When the sample has been played, it is supposed to delete the entry in the coll.
Here is the main patch
And here is the sub patch used in poly~ (you can name it _player)
The thing is that everything seems to be working fine, until I start to be frenetic (which will obviously be the case live). Some weird numbers get inside the coll, some entry are numbered by numbers never sent, and I often even have multiple entries with the same identifier:
40, 0;
40, 0;
40, 0;
40, 0;
To replicate, you can drop an audio folder and click Play Random. If you wait for the sample to finish playing, the corresponding ID in the coll should be deleted. But if you click Play Random several times, some entries remain in the coll. If you check whether some numbers have been sent or not, this is usually not the case.
Am I facing a threading problem? Where are these numbers coming from?
i suppose you didnt take into account that readong from disk and/or freeing the buffer is not thread safe and then at some position message order gets lost. did you debug it yet?
you should redesign the whole thing.
replace random with urn and it will not repeat genearted number till all
get output.
@Roman Thanks. I didn't know about the thread safety issue.
@Source Audio The thing is that random here is just for demonstration purpose. The sample request will come from a pre-analyzed map of all the samples that I navigate. The idea is to load in buffer the 10 nearest points only, and once a sample is loaded I don't want it to be loaded again.
I tried to get out from the poly~ the availability checker, and simplified the patch but with no success. Still unseen numbers getting inside the coll.
How would you keep track of loaded samples inside a poly~, while knowing if it has been freed or not?
get all colls out of poly subpatchers and keep only 1 coll in main patch.
send all messages to poly instances using target messages, which will then be stored in coll,
like index 3 means target 3 (poly voice 3), then insert sample name to know it was loaded
into that voice.
when target finishes playing you do whatever you want with that information.
it is trivial task to do so.
To exclude samples from "available" list - there are soo many ways to do that,
but I won't go into options without knowing exact & simple
layout of what you want to achieve.
I can't really follow the whole logic and what should be random etc
@source audio Thanks. I think I finally found it.
The problem seems to come from the delete message sent to coll. I don't know why, but it seems that it adds random numbers inside the coll when there is a lot going on.
Here is some kind of solution, pre-adding all samples ID and turning them to 0 when they are loaded.
And here is the subpatch used in poly~
Still a lot of improving potential, if this 2 patches are what you want to use,
and not just example of the problem.
loading files into buffer instead of using sfplay is waste of time and memory.
sfplay will be faster than loading large files into buffer.
Do you also use compressed audio files ?
They get converted to wave or aif every time max loads them into sfplay
and leaves them in temporary folder even if one doesn't use them later.
That applies also to playlist and such.
buffer import also converts the file, but does not use temp files.
I would test which approach is more efficient for you needs,
it depends how large audio files are, and in case of uncompressed wave or aiff
it would be better to use sfplay.
Here is simplified version using sfplay and umenu - grab instead of dict
Also checking of busy samples and play slots is done differently,
but based on your design.
One could easily adapt it for buffer based playback.
if using buffer than why size 0. at play end ?
it will anyway get resized with next sample load.
Thanks, that's a lot of improvement indeed. I didn't think of sfplay~ because I wanted to use the crossfade feature of play~, but after seeing your patch I think having 2 sfplay~ for crossfade in each subpatch of poly~ might be a better idea.
I only use uncompressed wav and aiff files, so glad to learn that I will save some conversion time. The size of those files is usually between 10 and 100MB, giving Max a little freeze each time I loaded a new one in buffer.
The idea behind the size 0. was to free some buffers in case I don't need to play another sample right away. But using sfplay~ might be a good solution, I am going to do some testing about this.
Thanks a lot for your help
you can also increase number of voices if using sfplay and
have crossfades by voice allocations.
but from your patch I see no way to perform any crossfade because
one player can only receive play message if allready stoped ?
I did not yet see any crossfade option in play~ object
I was talking about same sample looping on itself with a crossfade.
I usually use play~ @loop 1 @loopinterp 1 @interptime 5000 for a nice and smooth crossfade when looping, working well with long ambiant loops.
I tried to have 2 sfplay~ for a similar looping feature, but that seriously damaged the whole process. I think that's because I have to know the duration of the sample with sfinfo~. For the time being I am just going to use the loop mode included, and I'll try to think of a better and cpu friendly solution. Maybe I'll just use perfectly looping samples.
If you are interested in the whole patch I'm using, here it is (you will need the Flucoma externals)
This is a 2D corpus explorer for lengthy files. You can easily adapt it for exploring with more dimensions (I usually work in 16D).
that long interpolation will not be available using sfplay.
you had no trace of looping in example patch so I did not consider that at all.
I guess you need to edit samples to loop properly, or then switch back to buffer
based playback.
if it is ambient sound, and you cut it to loop +- perfectly, it will need fade in at start
if played by sfplay.
sorry but I have no ircam flucoma stuff installed, so can't really check your patch.