Sampler referencing a very large library.
Hello~
I’m working on a project that involves playing relatively short samples from a very large (theoretically infinite) library. I’ve researched a few techniques but wanted to see if any of you more experienced patchers could impart any advice before I really dig in.
Right now the very early version of the sampler portion of the patch is simply a group of 10 or so sfplay~ objects that open and play samples as another object sends them filenames in rhythm. Obviously not ideal, I’d like to build something that’s more robust and scaleable as the patch gets bigger.
I understand the difference between sfplay~ and buffer~ and would prefer to read from a buffer~ as it’s snappier and offers more control. I’ve looked into using a polybuffer~ (v5.1.9 with the external) that dynamically loads and unloads sample sets as needed, but I can’t see a good way of *unloading* samples without wiping the whole buffer and rewriting (impractical given the size of the library). I’m also not sure if this is the best way to go to begin with.
One more potentially important data point is that I’m working on a machine with only 2GB RAM (upgrading hopefully soon), but given that I want this patch to be able to handle any amount of samples it hopefully shouldn’t matter too much.
Any advice or guidance would be greatly appreciated, thanks in advance for your time.
-jic
Why not use a plugin like Kontakt? I would imagine it’s buffering/disk reading is quite optimized and will be much easier to set up.
Are you triggering them rhythmically?
How short is relatively short?
There’s also concat oriented playback stuff like Catart, which play back thousands of files (or hundreds? it’s gigs worth for sure).
Sorry I can’t be of more help.
Thank you both very much, those are both great suggestions. The samples are triggered rhythmically so snappiness is definitely a priority, I’d say 90% of them are under 3 seconds, and there are many gigs worth.
I think some sort of plugin is probably the best way to go in the long-term but will definitely try DEvo’s suggestion for this iteration, if only to learn the object a little better.
cheers,
-j