Jean-Philippe Jullin

I'm looking to dynamically load sounds into a buffer using 

 during a live performance. I don't want to use 

 because I want several hundred sounds to be accessible, but as they last between 30sec and 10min each, the total is about ~30GB.

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 

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.

comment

tosymbol

live.text

random

number

message

live.gain~

ezdac~

prepend

poly~

dropfile

zl.len

dict

loadmess

zl.slice

umenu

zl.rev

join

counter

outlet

inlet

sprintf

coll

qmetro

And here is the sub patch used in poly~ (you can name it 

deferlow

buffer~

thispoly~

thru

gate

out~

play~

loadbang

fromsymbol

print

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: 

To replicate, you can drop an audio folder and click 

. If you wait for the sample to finish playing, the corresponding ID in the 

 several times, some entries remain in the 

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

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.

Hi everyone,
I'm looking to dynamically load sounds into a buffer using poly~ during a live performance. 

dynamic-buffer-loading-using-poly~

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?

replace random with urn and it will not repeat genearted number till all

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.

 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.

 the availability checker, and simplified the patch but with no success. Still unseen numbers getting inside the 

How would you keep track of loaded samples inside a 

, while knowing if it has been freed or not?

@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

when target finishes playing you do whatever you want with that information.

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

I can't really follow the whole logic and what should be random etc

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.

. I don't know why, but it seems that it adds random numbers inside the 

Here is some kind of solution, pre-adding all samples ID and turning them to 0 when they are loaded.

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.

Still a lot of improving potential, if this 2 patches are what you want to use, 

loading files into buffer instead of using sfplay is waste of time and memory.

sfplay will be faster than loading large files into buffer.

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.

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

Here is simplified version using sfplay and umenu - grab instead of dict

Also checking of busy samples and play slots is done differently,

Player-SF.zip

One could easily adapt it for buffer based playback.

it will anyway get resized with next sample load.

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 

 because I wanted to use the crossfade feature of 

, but after seeing your patch I think having 2 

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.

 was to free some buffers in case I don't need to play another sample right away. But using 

 might be a good solution, I am going to do some testing about this.

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.

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. 

you can also increase number of voices if using sfplay and 

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

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. 

play~ @loop 1 @loopinterp 1 @interptime 5000

 for a nice and smooth crossfade when looping, working well with long ambiant loops.

 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 

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)

LengthyCorpusExplorer.zip

This is a 2D corpus explorer for lengthy files. You can easily adapt it for exploring with more dimensions (I usually work in 16D).

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.

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

if it is ambient sound, and you cut it to loop +- perfectly, it will need fade in at start

sorry but I have no ircam flucoma stuff installed, so can't really check your patch.

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.


Dynamic buffer loading using poly~