i'm trying to build time stretch patch.
any advices are welcome.
-
Time Stretching
-
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 course
best
__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.
-
Good point. You should also look at the phase vocoding patches if you really want to do some awesome time stretching/contraction. It certainly won't give you a grain-y sound, which might be what you're interested in, but it's very smooth sounding.
They're kind of a lot more difficult to understand, but I definitely like the sound.
-
Ha! Strange how I was just working on this very same thing and then find a thread with a patch on here so similar to mine. The variable envelope is an awesome idea maelstorm.
What I'm trying to do in my patch is make it into a sample looping abstraction in which many will be loaded into a parent patch to be performed. The problem I'm having is a gap at the end of the loop caused by the grain section trying to read past the end of the sound file. I'm trying to come up with an elegant way to stop this (vanilla preferred).
I attached my version but it's still in the ugly stages, the gui items will be replaced with inlets and the dac~ with an outlet~.
-
That's something I didn't handle in my patch, either. However, you could solve it like this:
(signal)
... [r $0-samples]
| |
[expr~ fmod($v1, $f2)]
|
[tabread4~ $0-file]fmod() is a floating-point modulo, so it's like [wrap~] except it doesn't have to be constrained with 0-1.
-
I didn't know about fmod, I should come to this forum more regularly!
-
@Maelstorm said:
That's something I didn't handle in my patch, either.
I have been experimenting with your patch and i find I can get it to work with shorter samples quite well but what can I do to modify it for use on an entire track of say 5 to 10 min in length?
-
You'd have to set the -maxsize flag in the message to [soundfiler] to something huge. By default, [soundfiler] won't resize an array to something larger than 90 seconds unless you do that. But even then, I think there is some kind of hard-coded limit, and so ten minutes probably isn't going to happen. You'd have to come up with a way to split the file into multiple arrays and cycle through them. I want to say this has come up in the forums before, so it might be worth searching around for a patch here.
-
So I have been experimenting with the timestretch2 and found the aliasing caused by the processing to be a little bit of an issue so I introduced a small 5th order low-pass filter and a cheby~ and find it improves the sound to a degree. Also I modified some of the characteristics of the sample playback which re-trigger the messages, I was finding it was not playing back audio on PD~ for MAC OSX until I reapplied the messages.
I'll post the solution to the extended sample time when I finally attempt it.
-
Any aliasing you get from playing it faster is already going to be applied before it hits those filters. If you wanted to get rid of it you'd have to stick the sample playback parts with the filters in a subpatch and in increase the samplerate using [block~]. I think the artifacts you're hearing are coming from the grains comb-filtering each other.
-
i remember some kind of cloud like time stretching / pitch shifting method...
i think it was based on the spectrum itself
but i don't remember the name of it
it was really complicated but maybe there is a pd version out there somewhere?pd redefining mathematics |expr fact(0)|==0
-
@Maelstorm said:
Any aliasing you get from playing it faster is already going to be applied before it hits those filters. If you wanted to get rid of it you'd have to stick the sample playback parts with the filters in a subpatch and in increase the samplerate using [block~]. I think the artifacts you're hearing are coming from the grains comb-filtering each other.
I'm finding that there was aliasing in general not just from the speed increase. Perhaps I am using the incorrect term for the effect as its more like bit rate reduction. I find that the filter chain at the end works well for the results I want. This is a technique I use to improve the quality of a DAC built in circuit. Plus the cheby~ can create some crazy sounds if the variables are modified.
You might be right about the comb-filtering of the grains though. I'm going to experiment with it a little more. I love this patch though, reminds me of spinning records.
