[PD] Good Time Stretching patches/advice?

[S.E.P.]

Hey Derek, list,

Many thanks for the abstraction, it made testing much easier. I find
overall that your patches add a metallic reverb-like sound
 to the stretched sample (not sure why that is). Also, probably due to the
randomized grains, there's a very irregular sound in the resulting stretch
- the harmonic spectrum of the contrabass sample (attached) fluctuates very
actively. The sax multiphonic sample (also attached) already has a
fluctuating sound - but it's a rhythmic flux that, in the stretch resulting
from your patches, becomes less regular. I wonder if there's a way to
address this or if these aren't inherent issues with the granular method of
time-stretching.

On another note, a user named "solipp" at the pdpatchrepo uploaded a good
time-stretcher, though it does have two small issues I haven't figured out
yet:
http://forum.pdpatchrepo.info/topic/9909/time-stretching-patches-any-recommendations/22

Best,
S E P

On Fri, Apr 22, 2016 at 11:11 AM, Derek Kwan <derek.x.kwan at gmail.com> wrote:

> 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...
>
> Derek
>
> =====================
> Derek Kwan
> www.derekxkwan.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20160422/3b977a51/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: testbasse-new.wav
Type: audio/x-wav
Size: 962984 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20160422/3b977a51/attachment-0002.wav>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wn04a-held4.wav
Type: audio/x-wav
Size: 281666 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20160422/3b977a51/attachment-0003.wav>