Eplusmusic

Basically I am trying to make a sampler that allows the user to select the audio files used from within a folder. So I have made a little patch which tries to load 64 files into 64 buffer~ objects so I can just send a "set (name of buffer)" message to the groove~ objects that I will be using.

I am also trying to find a way to keep sampling information such as loop points, looping on/off, direction etc, within the patch from the last time it was opened. It is pretty important that the same samples are written into the same buffers every time also.

Basically I am trying to make a sampler that allows the user to select the audio files used from within a folder. So I have made a little patch which tries to load 64 files into 64 buffer~ objects so I can just send a "set (name of buffer)" message to the groove~ objects that I will be using. 

I am also trying to find a way to keep sampling information such as loop points, looping on/off, direction etc, within the patch from the last time it was opened. It is pretty important that the same samples are written into the same buffers every time also. 

loading-64-files-into-64-buffers

you can store the information and assignment to a [coll]-file, which is to save whenever you change a value and to read on startup.

Thanks, but I suppose the issue is that all of the files will be different every time the patch is used. I guess the way to make sure this works is to re-name all of the files, or write them into another folder, with a reference number.

I think I can do that with some Java class or something.

https://cycling74.com/tutorials/week-22/


well you can store the other information, no matter if the filename is the same. have a coll with 64 indices and store loop, start, end, direction etc. thats all no problem. if you want to load the last file, add the filepath as well. if not, you'll have to load the samples manually each time you start the patch.

i have done this all as part of my central patch - but only with 8 buffers due to the cpu-load when you use too many buffers. i worked around it by having 8x4 filepaths stored. so i can choose of 4 different samples per slot/buffer via one mouseclick.

well you can store the other information, no matter if the filename is the same. have a coll with 64 indices and store loop, start, end, direction etc. thats all no problem. if you want to load the last file, add the filepath as well. if not, you'll have to load the samples manually each time you start the patch. 

i have done this all as part of my central patch - but only with 8 buffers due to the cpu-load when you use too many buffers. i worked around it by having 8x4 filepaths stored. so i can choose of 4 different samples per slot/buffer via one mouseclick.


So would you say that using so many buffers will make everything super slow, even if they are just used for referencing and calling up into four groove~ objects? What I am trying to accomplish is to have all of the files be organised as lights on the Launchpad, letting the user select which samples they would like to use for each groove~ object by holding down modifier keys.

Thank you for your advice on the coll thing.

So would you say that using so many buffers will make everything super slow, even if they are just used for referencing and calling up into four groove~ objects? What I am trying to accomplish is to have all of the files be organised as lights on the Launchpad, letting the user select which samples they would like to use for each groove~ object by holding down modifier keys. 

Thank you for your advice on the coll thing.


it may depend on your hardware ressources, so just try. but i had troubles with a patch of 16 open buffers some months ago (on xp, old ibm t41 notebook - on a newer desktop pc all was fine). making up my mind i think to have read about a basic rule regarding msp/signal based-objects having a certain hunger. maybe because they´re always working in realtime.

why not load all 64 files into one polybuffer? the grooves can then be set with 'set polybuffername.x' messages. Also the polybuffer can remember what folder you loaded the files from and auto load it every time the patch is opened.

I'm not one hundred percent if they are always in the same order but there may be a way to sort them inside the buffer.

Also buffers drain RAM correct as they load the files into memory rather than reading them from the disk?

the way i do this is by loading a buffer~ object into poly~. in that case i use poly~ only as a buffer storage place. then i use the "thispoly" object (inside poly~ of course) to generate buffer names. the buffer names could be just numbers or you can add a string and an integer together with combine object, so you would have for instance "buffer_1" in first voice of poly~, "buffer_2" in second voice of poly~ etc. in the same way, you can automatically load as much samples as you want (you just have to name them appropriately, buffer_1, buffer_2 etc,...). and also it is better to load samples with message "replace" than "open", so the size of the buffer~ matches the size of the sample loaded.

that way i was using around 300 buffers without any problems. samples were long from 3 to 8 seconds.

Loading 64 files into 64 buffers.