On Apr 21, S.E.P. wrote:
> Hey Derek (and list)
>
> Thanks for the clarification. I put together a test patch for your
> fgraintstr~ (tesuto.pd) and tested it with the attached .wav file (you need
> to click on the "read" message). It would seem it works without inputting
> any values into the left inlet, which is tantamount to a freeze, I
> assume...?
>
> I'm not sure what a good grain rate is... maybe in the 20s or 30s. In
> general, it sounds a bit fuzzy and electronic and the harmonic spectrum is
> very unstable... but I'm probably doing something wrong. Any more tips?
>
Hey,
I've attached a patch for you to test out. It sounds fine with smaller
soundfiles, but kinda gets unstable with larger soundfiles due to the
heaviness of the abstraction...I wrote the abstraction originally for a
piece that I ported from supercollider that live-stretches a kalimba to
something like 100 times it's original length so I didn't have to use
super long soundfiles. I also had the grainrate around 5 ms so that
means grains at length 5*32 = 160 ms. Also I didn't do any
normalization in these abstractions (but in my external version I do) so
note in the test patch I've attached I multiply the outputs of the
fgrainstr abstractions by 0.25. Note that fgrainstr2 doesn't do any
transposition, but it deals better with longer sound files due to
indexing and float precision.
If you know how to compile stuff, you can also check out my external
version that's also on my github page in the dxkpure repository. That
whole thing is sort of in a pre-release stage because I haven't figured
out the build process quite yet and my main machine runs ubuntu so I can
only provide externals built for linux so far... I've kind of moved my
efforts from making abstractions to making externals in interests of
efficiency...