i'm trying to build time stretch patch.
any advices are welcome.

http://www.pdpatchrepo.info/hurleur/t_stretch.rar

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~.

http://www.pdpatchrepo.info/hurleur/time_stretch.pd

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.

http://www.pdpatchrepo.info/hurleur/timestretch2_mmb_bd.pd

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?

@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.

A very impressive patch!

Hi, I am currently working on a timestretching/pitchshifting loop player based on this 2-grain implementation. My problem is I can always hear the frequency of the grains themselves in a sort of amplitude modification effect, even though the second grain is out of phase to fill up the empty spaces in the first one. With longer grains it sounds like a tremolo, with shorter it sounds like a ring mod. Changing the window shape doesn't seem to help.

Is there any way to make this effect go away?

Hi wkc
Can you attach a patch?

hi!!

really insane nice patch (FIRST OF all)

i've been using it for a while... and sometimes, when i load the sample it doesnt play.... does anyone have the same problem??
sometimes it doesn't have this bug...other times yes....

thanks for the patch by the way...really nice one!!