Loading a dir of sounds into individual buffers w/o typing it all out by hand
Some of you may remember this adventure. I'll not recount the whole shebang and just cut to the current status and query here in a new thread.
I am trying to make a sample playback patch that uses buffer & groove instead of play (for timing, I already started with sfplay and preloading and that didn't work) and I want to be able to trigger more than one sample at a time, so I am trying to get groove/buffer & poly~ to work as my sample playback engine.
I think that this small patch actually works. Perhaps this isn't the best way to do it, but testing with 6 very long sound files it seems as this will trigger additional sounds and through target/poly~ will continue playback even when a new sound is triggered.
So.. here's my question, and the next wrinkle. I have a directory with hundreds of perfectly manicured files. I really do not want to have to add:
read /Users/kpp/Foobar/Yomama/Sampler/snd/filename1.aif
|
|
[buffer~ sample01]
read /Users/kpp/Foobar/Yomama/Sampler/snd/filename2.aif
|
|
[buffer~ sample02]
etc. & co.l
For hundreds of sound files. That would be a sheetload of typing, take up gobs of screen real estate and also, i like to be able to add, subtract, edit etc. my sound in my soundfile dir over time.
How can I point a patch to a sndir and have it slurp down all the sounds in that dir, creating a buffer for each sample, and then how do i call up a sound and sent it to poly.
cheers,
-kp--
There is an abstraction in the CNMAT MMJ depot called "multibuf" that does exactly this.
It's in /MMJ-Depot/modules/Soundfiles-sampling/
mz
The scripting approach has worked for me in the past.
Try the patch below and see if it is useful to you.
MIB's solution only seemed to work on some files. I dumped a folder and some buffers were created. But i also got a message in the max window that said:
Fromsymbol doesn't understand "int"
and script connect: can't make connection (buffer3 0 -> dummyConnect 0)
---
The CNMAT multibuf patch seems to work. But it i am not quite sure how to use it or integrate it with my existing patch and where it i goes. Particularly since i am using poly~ it is unclear how multibuf would get plugged in to an actual patch with groove and poly. ... I'll look at it some more and scratch my head.
so, i guess... looking at multibuff the buffers are generated automagically (emphasis on magic in this case! that is crazy) & once they are there it don't matter where them suckas are in the patch they are now available to groove~ ... so what is the strategy for using this? I guess you can dump the buffer names to a coll and then use the coll as a faux hash table/dictionary? with the number as key and then the string for the buffer name returned as value? All that coll stuff in the patch makes me think that is how this is commonly used? I may give that a whirl.
Thanks for responding.
-k--
woooo.... okay ... yeah. That actually worked. It's not perfect and this patch is really oversimplified. But seems like it does work. The effing holy grail. groove~/buffer~ & poly~ with the point & burp autoloader code. I spent half the summer trying to these three requirements to work. I had them all working separately except the last bit. Buffers from a dir, groove & buffer for timing + poly~ for polyphony. No one could get this to work, or if they could they were keeping the answers to themselves. I can't beleeb it.
Still not 100% about how i am using poly.. but it does seem to work.