I was hoping to build a variable-speed sound file streamer abstraction -- like readsf~ but with a rate inlet (particularly for correcting a mismatch between the file's sample rate and the DSP sample rate).

I was hoping to do it like this:

• Allocate an array with x frames.
• Upon "cue," load x/2 frames at the beginning of the array.
• When playback takes off from frame 0, load the next x/2 frames into the second half of the array.
• When playback crosses the halfway point, load the 3rd x/2 chunk into the beginning of the array.
• At this point, then, a phasor can just read forward through the array, and loop back to the beginning. At every half-transition, load data into the half of the array that isn't being played.

I quickly run into gaps in soundfiler's interface.

• "-maxsize" resizes the target array -- there appears to be no way to load partially into an array.
• There also doesn't seem to be any way to read starting at index 'a' in an array. "-skip" will skip frames from the file, but there isn't a flag for where to start putting data into the array. (Compare SC, with parameters fileStartFrame, numFrames and bufStartFrame for the buffer read message.)

This was to distribute a multichannel fixed-media work. I was thinking Pd because the download size is small. But I think I'm going to have to take this back to SuperCollider because there's a VDiskIn built-in -- can just use it, not spend time hacking it.

In any case... are there any workarounds for those two limitations? (I guess I would need two arrays -- I was hoping to avoid that because switching the table name sample-synchronously also sounds a little bit tricky.)

hjh

@ddw_music I think I built something similar to what you're describing for @cfry, see https://forum.pdpatchrepo.info/topic/13518/readsf-varispeed. The second version with the shorter buffer wraps the playback point correctly. The idea is to use [switch~]'s bang feature to run [readsf~] faster than realtime and to read your sound file into a buffer that's a multiple of the block size so that you don't have the control rate synchronization problem you alluded to. But yes, it's tricky to get right.

@ddw_music Maybe [player~] from the ELSE library could be an option?

Good tips from both @jameslo and @manuels, thanks

EDIT: FWIW, I think I'll go with else/player~. My initial attempt with it overcomplicated things because I was expecting to have to manage sample rates myself, but... it handles all of that automatically. Thanks for the suggestion!

hjh