I'm new here. Apologies if this is in the wrong place.

Hello All,

I am working on a performance piece in which a live input needs to be timestretched.

I understand timestretching a live input may be impossible, however I was hoping a granular delay approach may work.

To help explain - if you imagine a delay box set to a very short delay time like 2ms, and a long decay time like 2 seconds, you would get a ringy layered delay effect. This is what I want to do but in a clear timestretched manner, but still layer the sounds as they come...

Does this make sense.

Can any one point me to a patch or technique ?

Thanks
Twogan

This all sounds very hopeful indeed. I'm glad I am not asking the impossible.

Many thanks indeed for the ideas and advice.

I am a beginner with PD and I am afraid a lot of this is going over my head ?

How long do you think it would take me as a beginner to get up to the level where I can make this patch myself ?

Are there any existing patches available that I can look at / modify ?

Is PD the best way to go to achieve what I need to do, in view of my inexperience ( I have used Processing, PD and arduino etc... before but always quite simple programs for very specific projects, usually involving sensor input, not audio processing ) ?

Many thanks in advance for your time on these questions

Twogan

The loadbang book by Johannes Kreidler has got a live input granular thingy, but I'm not sure if it does what you want
http://www.pd-tutorial.com/english/ch03s07.html#id431485

hi Twogan,

Feel free to mess with this patch for RT time-stretching.

I do think PD is a very good (the best?) choice for this kind of manipulation. The learning curve may be a bit steep at first, but there are a lot of good resources like the book Alexandros linked, and these forums of course!

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

Many Thanks for this.

I cannot see the adc~ or dac~ so how do I route my mic input to this ?

Very Sorry for my naivety..

T

Hi,

Sorry I didn't specify this before: you can use this as an abstraction inside another patch (thanks to the [inlet~] and [outlet~] objects).

Or you can just replace [inlet~] with [adc~] and [outlet~] with [dac~] for a quick test.

Great. Thanks for the clarification GC

OK so I have been experimenting with the timestretch RT.pd patch linked above.

I have found that it is exactly what I need however - it has some issues.

I find that there is a big variation in the 'latency'. When I first use the software its not too bad. but if I move the sliders it becomes very very long - up to about 8 seconds... So not really usable...

Can anyone see why this might be the case? Perhaps it is just on my set up...

Thanks
Twogan...

Hi twogan,

It's not really latency (in the usual sense). The time-stretching in this patch is based on a delay line: this means you have a maximum length for the segment you're stretching (or compressing), but also means that once you've streched your input a bit, the output will be some amount of time "late" in relation to the input, even if you bring the speed back to 1.

You can think of it this way: if you have two runners at the same speed, and one of them slows down for a while then gets back to the original speed, the first one will get (and remain) ahead.

More technically: bringing the speed back to 1 only stops the [phasor~] responsible for varying the delay time, it doesn't bring its output back to 0. You could force it to do that, I suppose, by sending a [0( message to its phase (right input) when the speed goes to 1. Haven't really tried it; might work, but might also give you some not-so-nice jumps.

Here's a way to do it (adding this to the existing stuff in the patch):

(speed slider)
\
\
\
\
\
[sel 1]
|
[0 (
|
[phasor~]

Or just connect the [0 ( to the [phasor~] phase and click it whenever you want to get your delay time back to 0.

Incidentally, the maximum delay time I put in that patch is 8000 ms, which is probably what you're experiencing after having slowed down your audio for a while. You can change that behaviour in the multipliers before and after the [phasor~] (for its frequency and range, respectively). If you want more than 8000 ms, you have to change it in the [delwrite~] as well. Note that this will affect how much of your audio stream you can stretch before a jump.

Hope this helps. Glad that it worked well - at least for a while.

GC - Thanks so much for the detailed reply.

I do understand your description. I like your runner metaphor.

I am again worried that I am trying to do the impossible.

I need to be able to constantly stretch a stream of incoming audio with no gaps or latency. I ultimately want to use this as an overall effect applied to the stereo mix of a live band playing. I want them to start playing vvvvvvveeeeeerrrrrryyyyyy sssssllllooowwwllllyyy wwwwiiiitttthhhh aaaaaa llllloooonnnnnggg sssstttttrrretchhh,,,,,,, ttthheeennn ggrraadduuaalllyy ddeeccrreeaassee tthhee ssttrreettcchh aammoouunntt aass tthey sspeed uup, uuntil aafter ssome ttime tthey aare jjust playing clean and tight.

To reiterate - the band would start by physically playing their instruments slowly, whilst there is a long stretch amount applied. Then as they start to physically play faster, we lower the stretch amount in accordance..

EG, if the source was a snare drum being hit once every 4 seconds, and each resulting hit sound was stretched to 3 seconds long you would end up with a nice one second gap. With a constant sound as an input (say a bass tone) we would end up with a massive noisy pile up of audio (which would be fine by me). If the snare hit and the bass tone were played together you would end up with a big noisey mess of bass tone over a nice 3 second long snare hiss...

Do you see?

To follow your runner metaphor I would need the runner to be constantly spawning hundreds of new runners who would slow down and fade away I suppose...

Its almost like to get rid of the delay in the patch below I would need very many versions of the patch taking an input once after each other in turn, all delayed by the same amount as the grain size?

i.e - So instead of 'turning off' the input whilst the stretch is done, its constantly 'on' and the stretched output is layered over itself...

Does this make any sense?

Its almost like I need the effect to function in the way a reverb does, rather than a time based thing...

Sorry, hope that makes sense. I am making my own head hurt trying to explain this

twogan

Hi,

I'm not sure I follow what you mean, or that what you want is actually a time-stretch.

In your example of the snare drum being hit once every 4 seconds, a stretched version of this would be snare hits every 5 seconds (if you stretch it a little), or every 8 seconds (if you slow it down by half). So you wouldn't have *at all* the effect you're describing with a "nice gap" (even if the attack itself would be stretched too, of course - but not that much).

You do seem to describe something closer to reverberation, you should look into that too.

You can try and use more than one instance of the abstraction, windowing the outputs, with the delay time resetting to 0 at each cycle and starting the stretch again. That's closer to "spawning runners" continuously, but it still wouldn't do what you described, I'm afraid.

-G

I think twogan wants to do something like the second effect in this video

which is done in Max. I'd really like to do something like that too, but even using the same objects (from cyclone) won't do it. If anyone can give some hints on how can this be done it would be great.

I tried to make a Pd version of the one in the video I posted. It kind of stretched the incoming signal, but it immediately shifts the pitch down quite a lot.
I've attached the patch so anyone who wants can improve it..

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

Hi Alexandros,

The [delay~] object in Max is, if I'm not mistaken, a delay in samples. The [z~] object in zexy does that sort of delay, but you can use [delwrite~] / [delread~] for that too, provided you place them in connected subpatches (like you did) in order to allow for delay times smaller than one block.
Not sure it would work exactly the same, though, especially with the [line]s connected to it.

You're getting transposition because of the Doppler effect (raising the delay time is like moving the sound away from you). The way to avoid that is to keep a constant delay time within a window, and move the delay time for the start of the window once you've read it and are about to read another one.
Basically, that's what I did in my patch.

The second effect on that vid is quite similar to what I get when stretching in RT, except that there the delay time goes back to 0 when they stop the stretching (whence the jump we hear). That can be achieved with the modification I added some posts back.

-G