If you're using the newest vanilla, the [array] object lets you get a range of a given size from an index onset as a list, and to put the list at an onset of another array. It's faster than I thought it would be. So, you could just load your files sequentially into one table and copy them from there, or you could load them all into their own table and copy each one separately. I don't know which would be faster. As long as you're not resizing the table each time you load, I'd probably go with the first option. Just remember that [soundfiler] runs synchronously, so you don't want to do any of this in the middle of the operation.
On Tue, Feb 23, 2016 at 2:49 PM, Samuel Burt <composer.samuel.b...@gmail.com > wrote: > I guess I've never seen a way to load multiple samples into a single > array. That might solve another problem I'm currently sorting out. How do > you do that? > > Sam > > > On Tue, Feb 23, 2016, 1:56 PM Matt Barber <brbrof...@gmail.com> wrote: > >> This is doable, actually, but not easy. [delay] and [vline~] both have >> subsample accuracy. It would be substantially easier if you could >> preprocess and deliver the sequence as one big message dump to [vline~]. If >> you loaded all of the files into one array (up to about 6:20 of audio at >> 44100) and kept tabs on where each one started and how long it was in >> samples and milliseconds, you could then feed [vline~] into [tabread~] to >> play the relevant chunk of the array. If you needed to be able to transpose >> them, that's a little harder because depending on how long the table was, >> you'd need to work in the message onset to [tabread4~]'s right inlet or >> face index degradation. >> >> On Tue, Feb 23, 2016 at 1:40 PM, Samuel Burt < >> composer.samuel.b...@gmail.com> wrote: >> >>> David, >>> >>> One thing I attempted and couldn't find a solution for was the >>> following, mostly owing to the limitation of interfacing with a 64 sample >>> block size. >>> >>> I wanted to have a directory of hundreds of audio recordings. Each one >>> would be a single wavelength from an interesting sound, like a bass >>> clarinet, marimba, harpsichord, tambourine, etc. Each would begin and end >>> at a zero crossing so you could chain them together to make complex >>> timbres. They could be chained in sequence, randomized, or loaded in >>> meta-data-matched chunks. I ran into a problem figuring out how to trigger >>> the next sound based on the ending of the last sound in a sample accurate >>> way. Sound file loading or even buffer playback triggering waits until the >>> start of the next block size before it updates. If you have a waveform that >>> lasts 205 samples (64+64+64+13), you have a gap of 51 silent samples before >>> the next waveform would start. Not only do you not get the continuous sound >>> you want, this winds up creating a periodic pattern with a frequency of 689 >>> Hz (44100/64). >>> >>> David, I like your idea "what (if anything) someone tried to do in Pd, >>> but couldn't given its limitations". I think this could be a wonderful >>> challenge if we could have a monthly thread like this where the best minds >>> among us come up with solutions to some of the hardest conceptual >>> challenges in Pd. >>> >>> I'm still struggling with loading dozens of files, audio dropouts, and >>> other similar problems. Someone else expressed frustration about Pd's >>> single-threaded status. I too have feared upgrading my computer based on >>> the limitations of current multicore processors (although realistically I >>> think we can all look at the "turbo-boost" level or whatever Intel calls it >>> to determine where our processor might run with a demanding patch. I >>> understand the fact that you can't run your audio process on multiple >>> cores, because it is a linear process. It would be great if the GUI could >>> run on a second core, a process that loads audio into memory could run on >>> third core, while GEM could automatically run on a fourth core. I don't >>> have any concept of how feasible that would be, though. Does the GUI in >>> pd-l2orc run on a separate core? >>> >>> Sam >>> >>> >>> >>> >>> >>> >>>> Message: 4 >>>> Date: Tue, 23 Feb 2016 09:01:06 -0800 >>>> From: david medine <dmed...@ucsd.edu> >>>> >>>> One thing I'd be interested in knowing about is what (if anything) >>>> someone tried to do in Pd, but couldn't given its limitations (apart >>>> from look/feel/convenience issues). >>>> >>>> >>> _______________________________________________ >>> Pd-list@lists.iem.at mailing list >>> UNSUBSCRIBE and account-management -> >>> http://lists.puredata.info/listinfo/pd-list >>> >>>
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
