<div dir="ltr"><div><div>Hey Derek, list,<br><br></div>Many thanks for the abstraction, it made testing much easier. I find overall that your patches add a metallic reverb-like sound<br></div><div> 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. <br><br></div><div>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: <a href="http://forum.pdpatchrepo.info/topic/9909/time-stretching-patches-any-recommendations/22">http://forum.pdpatchrepo.info/topic/9909/time-stretching-patches-any-recommendations/22</a><br><br></div><div>Best,<br></div><div>S E P<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 22, 2016 at 11:11 AM, Derek Kwan <span dir="ltr"><<a href="mailto:derek.x.kwan@gmail.com" target="_blank">derek.x.kwan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Apr 21, S.E.P. wrote:<br>
> Hey Derek (and list)<br>
><br>
> Thanks for the clarification. I put together a test patch for your<br>
> fgraintstr~ (tesuto.pd) and tested it with the attached .wav file (you need<br>
> to click on the "read" message). It would seem it works without inputting<br>
> any values into the left inlet, which is tantamount to a freeze, I<br>
> assume...?<br>
><br>
> I'm not sure what a good grain rate is... maybe in the 20s or 30s. In<br>
> general, it sounds a bit fuzzy and electronic and the harmonic spectrum is<br>
> very unstable... but I'm probably doing something wrong. Any more tips?<br>
><br>
<br>
</span>Hey,<br>
<br>
I've attached a patch for you to test out. It sounds fine with smaller<br>
soundfiles, but kinda gets unstable with larger soundfiles due to the<br>
heaviness of the abstraction...I wrote the abstraction originally for a<br>
piece that I ported from supercollider that live-stretches a kalimba to<br>
something like 100 times it's original length so I didn't have to use<br>
super long soundfiles. I also had the grainrate around 5 ms so that<br>
means grains at length 5*32  = 160 ms. Also I didn't do any<br>
normalization in these abstractions (but in my external version I do) so<br>
note in the test patch I've attached I multiply the outputs of the<br>
fgrainstr abstractions by 0.25. Note that fgrainstr2 doesn't do any<br>
transposition, but it deals better with longer sound files due to<br>
indexing and float precision.<br>
<br>
If you know how to compile stuff, you can also check out my external<br>
version that's also on my github page in the dxkpure repository. That<br>
whole thing is sort of in a pre-release stage because I haven't figured<br>
out the build process quite yet and my main machine runs ubuntu so I can<br>
only provide externals built for linux so far... I've kind of moved my<br>
efforts from making abstractions to making externals in interests of<br>
efficiency...<br>
<div class="HOEnZb"><div class="h5"><br>
Derek<br>
<br>
=====================<br>
Derek Kwan<br>
<a href="http://www.derekxkwan.com" rel="noreferrer" target="_blank">www.derekxkwan.com</a><br>
</div></div></blockquote></div><br></div>