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