@Derek Kwan Many thanks for your reply and your patches. I confess that I have a poor understanding of arrays and the related object and tend to use objects/abstractions that take an audio/open panel input. With your patches, as with some others I've seen, I need to put "pos (samples)" into the inlet and I'm not sure what that means. Also, while the 1st argument is the name of the array to be read, I don't know what "catchname" means for the 2nd argument.

@Jaime Oliver Have you used the Tom Erbe patches yourself? I downloaded the pack at this student's website: http://www.cooperbaker.com/home/code/pd%20spectral%20toolkit/ . Oddly, Windows tells me there are redundant files and asks if I want to replace them when I unpack it in a clean folder. I also add the path in my preferences and am unable to access the .pd_darwin files...

Best regards,
S E P

On Tue, Apr 19, 2016 at 2:58 PM, Derek Kwan <derek.x.kwan@gmail.com> wrote:
> Obviously, I'd prefer a unified solution that works for a wide variety of
> samples. Any advice?

Hello SEP (and list),

Another route is the granular route.

I've got a bunch of abstractions that attempt to replicate
SuperCollider's Warp1 UGen. Basically the idea is to have grains occur
one after another in a more-or-less fixed rate (with some randomness
thrown in so you don't get a pitch from the grains themselves) and
choosing the duration of each grain so that they overlap each other (I
can't remember what I chose, I think something like 32x overlap? I think
the default rate in Warp1 is 8x but I never managed to get it sounding
good with that low of an overlap). I think as well as time-stretching,
you have the option of pitch shifting (at least in fgrainstr).

fgrainstr needs fgrain (which is a "grain voice") and tukeymaker (which
defines the window shape of each grain) and uses tabread4 if I remember
correctly.

fgrainstr2 needs fgrain2 and tukeymaker and uses tabplay to get around
the issue of very large index numbers.

With these abstractions, you can go down to a playback rate of 0. I
didn't really code these abstractions with other eyes in mind, but I
think they're commented enough to be useful.

I've also started making these into externals but I'm not sure if they
sound as good as the abstraction versions quite yet (still working out
the kinks). Instead of a Tukey window, I opted in this case to use a
standard cosine window.

Here's the link to the abstractions on my github:
https://github.com/derekxkwan/pure-data-abstractions/tree/master/fgrain

Derek Kwan


=====================
Derek Kwan
www.derekxkwan.com