i'm trying to build time stretch patch.
any advices are welcome.
-
Time Stretching
-
Actually, I think I may have been a little hasty in my reply and realize that just saying making the speed constant doesn't make complete sense. The speed should remain constant. I think the problem is that the grain lengths get larger as the overall duration gets larger, and you have grain lengths associated with playback speed. This is where the windowing comes in handy. The grain size should correspond to the size of the envelope, not how long it takes to playback a certain segment of audio, as you have now. The playback part should be a constant speed, and the window should get longer or shorter. And they should overlap, too, so they crossfade in and out with each other.
-
Okay, so I started modifying your patch, got a little excited, and ended up making a completely new patch.
I made the grain size independent of the playback speed, and also made an adjustable window. I also used two overlapping grains to smooth it out. There's comments in the patch, and any other ideas are welcome. -
Wow diplipito & maelstrom, very usefull stuff... thx for sharing this one.
|] [] |.| ][|-| -- http://soundcloud.com/domxh
-
Maelstrom, great job man
thank you.domien
thanx for comment
-
Maelstrom, cool idea ,using phasor~ instead of metro.
now I m playng with phasor's phase. -
One more thing (uncompleted, work in progress)
-
I had a bit of fun with this patch...I don't really know too much about PD and am far below average as a programmer.
I replaced the standard timestretch playback rate with a random value between 100% and -100% run through a metro whose rate is controlled by a slider.
It is awesome for quickly glitching some samples.
-
I just have been looking at you timestretch patches. Look great and very useful, but I cannot get them to work as I seem to lack the edge~ object and the speedlimit object (both in Pd-0.42-5 and Pd-extended). I'm a PD beginner, so any help as where to get these, or bypass, or 'emulate' them would be greatly appreciated ... Thanks!
H -
These objects are both from the cyclone library, which is included with Pd-extended and should load with the default settings. Otherwise, you'll have to add it to your path. Does this line not show up in the Pd window when Pd-extended starts?
libdir_loader: added 'cyclone' to the global objectclass path
-
Thanks for the reply, Maelstorm. No, a cyclone library is not loaded. I searched for it, and found *inside* the Pd-extended Mac package a cyclone map, containing files named edge~.pd_darwin and speedlim.pd_darwin. That is not a map that I can indicate as a startup path for, as it is *inside* Pd.
But I copied them to another map. Now the patch loads completely, and yes indeed, works! (In fact I also installed the latest version of Pd-ext: the read me *does* say that by default all these libraries should load; but apparently they don't ...)
Anyway.
Thanks a lot for the help. I want to implement timestretch as part of a sound-scene for the rjdj iPhone app, but for that I will need to bypass the edge~ and speedlim, as rjdj only gives acces to what is available in Pd-vanilla. Any hints as to how to do without would be greatly appreciated; and used with due credits of coursebest
__hars
http://harsmedia.com -
this patch should do pretty much the same as speedlimit. at least, i hope so ....;)
edit: what does edge~ do?
-
[edge~] outputs a bang when a signal goes from zero to something out its left outlet and when it goes from something to zero out its right outlet. So by doing this:
[phasor~]
|
[expr~ $v1<.5]
|
[edge~]you can detect when a [phasor~] has jumped from 1 to 0 at the end of it's phase. There is a downside, though, that didn't really occur to me when I made this patch: [edge~] only sends its bangs at the end of block boundaries, so it's not really sample accurate, which was what I was going for with the [phasor~].
With this patch you might be able to replace the [phasor~] approach with [metro] and [vline~]s. In fact, since those don't conform to block boundaries, it might technically be better.
-
Okay, take that last post I did and fuck it in the ass. [metro] and [vline~] is a stupid idea. [samphold~] works much better and is sample accurate (I always forget about [samphold~]!). I replaced the [edge~]->[snapshot~] combo with [samphold~], and now it is sample accurate and sounds much smoother, and it's vanilla! (Sort of, [speedlim] is just to keep the gui from doing to much work; you might not really need it, or you could use toxonic's alternative.)
-
@ookoi: take a look at this link to see if it fixes your start up preferences:
-
Thanks for all the help, guys! Working on it now ! ...
_hars
-
One more grain sampler
I have added pitch shift control. -
possibility for grainsize adjustment would be nice.
-
For doing time stretching/contraction I found examples B.12 and B.13 under the audio examples in the Help Browser of Pd very helpful. diplipito and maelstorm, your patches are pretty similar to what's going on in these examples.
Personally, I've just used a vline~ for the playback position which makes it easy to go forward or reverse. I suppose controlling it is a little messier though. -
Ha! I don't think I've ever looked at those patches; they are pretty similar. As for the forward/reverse thing, sending [phasor~] a negative frequency will create a down ramp, so it can easily go in reverse as well. In the patch I posted, just change the speed to a negative percent. [vline~]'s nicer for one-shots.
