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!!