On Apr 20, S.E.P. wrote:
> @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.

Hey,

Sorry, I should get around to documenting these abstractions a bit more.
fgrainstr2 is a bit more well documented than fgrainstr and I'll get
around to specifying things more clearly, which I will do right now...

THe first inlet in both are like tabread4~ in that you index into your
soundfile (loaded by soundfiler) by sample. A normal sample rate Pure
Data is run at is 44100 Hz (you can find this value by banging
samplerate~) so to read through a soundfile at a normal rate, you'd
index into the object (tabread4 or my fgrainstr) from 0 to 44100 over 1
second to play back the first second at a normal speed and from 0 to
22100 over 1 second to play through the first half second at half speed.
You could do this indexing by using something like phasor~ or even
easier, line~ by first sending the message 0 to line~ then the message
"44100 1000" to ramp to 44100 over 1 second.
The audio examples included with Pure Data (namely the ones at the
beginning of B) and the help file for soundfiler explain how PD deals
with soundfiles more clearly that I just did...

As for the specifics in dealing my abstractions, you only really need to
deal with fgrainstr and fgrainstr2 (but make sure that
fgrain/fgrain2/tukeymaker are in the same folder). You don't even need
to open those other abstractions, they're just there to help the main
abstractions fgrainstr and fgrainstr2 do their business.

Derek

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