I know there's been some discussion about time stretching samples and all, since I've searched the forum for it, but what I wanted to know was what those of you who've tried various ways prefer.

Which method has proven succesful for you guys? I have a stack of externals that say they do the trick, and some tips that don't need externals, like phase-vocoding...

So what'll it be? Which one's good and not too processor greedy?

I know there's been some discussion about time stretching samples and all, since I've searched the forum for it, but what I wanted to know was what those of you who've tried various ways prefer.
Which method has proven succesful for you guys? I have a stack of externals that say they do the trick, and some tips that don't need externals, like phase-vocoding...
So what'll it be? Which one's good and not too processor greedy?


time-stretching-yet-again

yeah, i saw a post of that somewhere. how is that working out for you? i've been thinking about many instances of something like that, so how does it treat the processor?

I use a combo of play~ and gizmo~ to do time change and pitch shift in one.

I have a buffer with a sound loaded (mono in this case)

I want to play any segment of that buffer with the following specified:

play~ alters the duration and transposes the segment

That transposition is "remembered" by computing the ratio

between the output duration and the segment duration.

The remembered ratio is multiplied by the output transposition

ratio so one gizmo~ can correct the effect of the stretch

I'm sorry I don't have complete example because my wrapper for this includes

a lot of my own objects that I have not yet posted.

Save this as play+gizmo~ and I'll try to put together a help file.

The idea is this...
I have a buffer with a sound loaded (mono in this case)
I want to play any segment of that buffer with the following specified:
    final duration (the stretch)
    segment start and end in buffer
    transposition interval
play~ alters the duration and transposes the segment
That transposition is "remembered" by computing the ratio
    between the output duration and the segment duration.
The remembered ratio is multiplied by the output transposition
    ratio so one gizmo~ can correct the effect of the stretch
    and transpose to the output pitch.

Here is what I put into a poly~
I'm sorry I don't have complete example because my wrapper for this includes
a lot of my own objects that I have not yet posted.

Cheers
Gary Lee Nelson
Oberlin College
www.timara.oberlin.edu/GaryLeeNelson

Here's play+gizmo~ modified to allow reverse playing along with a simple

And this as play+gizmo.help in the same folder.

Here's play+gizmo~ modified to allow reverse playing along with a simple
help file.

Quote: Gary Lee Nelson wrote on Mon, 18 February 2008 19:13

----------------------------------------------------

> I use a combo of play~ and gizmo~ to do time change and pitch shift in one.

But you shouldn't forget to mention that this solution always has an inherent latency, depending on the window size. If you make the window size small, the shifting/stretching quality is less, if you make the window size big, the latency is larger.

Quote: Gary Lee Nelson wrote on Mon, 18 February 2008 19:13
----------------------------------------------------
> I use a combo of play~ and gizmo~ to do time change and pitch shift in one.
>

Yes, latency is an issue. I love to hear about alternate methods of

On 2/18/08 4:33 PM, "Mattijs Kneppers" wrote:

> Quote: Gary Lee Nelson wrote on Mon, 18 February 2008 19:13

> ----------------------------------------------------

>> I use a combo of play~ and gizmo~ to do time change and pitch shift in one.

> But you shouldn't forget to mention that this solution always has an inherent

> latency, depending on the window size. If you make the window size small, the

> shifting/stretching quality is less, if you make the window size big, the

Yes, latency is an issue.  I love to hear about alternate methods of
accomplishing this.

On 2/18/08 4:33 PM, "Mattijs Kneppers"  wrote:

>
> Quote: Gary Lee Nelson wrote on Mon, 18 February 2008 19:13
> ----------------------------------------------------
>> I use a combo of play~ and gizmo~ to do time change and pitch shift in one.
>>
>
> But you shouldn't forget to mention that this solution always has an inherent
> latency, depending on the window size. If you make the window size small, the
> shifting/stretching quality is less, if you make the window size big, the
> latency is larger.
>
> Mattijs

Just did a comparison. I changed gizmo parameters from 1024 2 to 4096 4.

The quality increased significantly but I am confused about latency. In my

application it would be an issue if there was a delay in the start of a

sound relative to the time I activate it. I don't hear a delay with either

setting. CPU load seems to double with 4096 4. I was expecting a factor of

Just did a comparison.  I changed gizmo parameters from 1024 2 to 4096 4.
The quality increased significantly but I am confused about latency.  In my
application it would be an issue if there was a delay in the start of a
sound relative to the time I activate it.  I don't hear a delay with either
setting.  CPU load seems to double with 4096 4.  I was expecting a factor of
4-8.

Quote: Gary Lee Nelson wrote on Mon, 18 February 2008 22:56

> Just did a comparison. I changed gizmo parameters from 1024 2 to 4096 4.

> The quality increased significantly but I am confused about latency. In my

> application it would be an issue if there was a delay in the start of a

> sound relative to the time I activate it. I don't hear a delay with either

Did you try to route the original sound together with the gizmoed one to the output? For me that illustrates the latency best.

The only alternative I know is granular synthesis, which has no latency. But as far as I know no one succeeded to make a real-time granular synthesis patch in max that -doesn't- have artifacts for a fair shifting/stretching range, like for example Ableton Live.

Quote: Gary Lee Nelson wrote on Mon, 18 February 2008 22:56
----------------------------------------------------
> Just did a comparison.  I changed gizmo parameters from 1024 2 to 4096 4.
> The quality increased significantly but I am confused about latency.  In my
> application it would be an issue if there was a delay in the start of a
> sound relative to the time I activate it.  I don't hear a delay with either
> setting.  

For my application, I am using only the processed sound. When I do use the

original it still goes through with "do nothing" parameters - 100% time

scale and transpose interval of 0 semitones.

However, I will run your suggested test in case this does become an issue

On 2/18/08 5:09 PM, "Mattijs Kneppers" wrote:

> Quote: Gary Lee Nelson wrote on Mon, 18 February 2008 22:56

>> Just did a comparison. I changed gizmo parameters from 1024 2 to 4096 4.

>> The quality increased significantly but I am confused about latency. In my

>> application it would be an issue if there was a delay in the start of a

>> sound relative to the time I activate it. I don't hear a delay with either

> Did you try to route the original sound together with the gizmoed one to the

> output? For me that illustrates the latency best.

> The only alternative I know is granular synthesis, which has no latency. But

> as far as I know no one succeeded to make a real-time granular synthesis patch

> in max that -doesn't- have artifacts for a fair shifting/stretching range,

For my application, I am using only the processed sound.  When I do use the
original it still goes through with "do nothing" parameters - 100% time
scale and transpose interval of 0 semitones.

However, I will run your suggested test in case this does become an issue
for me at some point.

On 2/18/08 5:09 PM, "Mattijs Kneppers"  wrote:

>
> Quote: Gary Lee Nelson wrote on Mon, 18 February 2008 22:56
> ----------------------------------------------------
>> Just did a comparison.  I changed gizmo parameters from 1024 2 to 4096 4.
>> The quality increased significantly but I am confused about latency.  In my
>> application it would be an issue if there was a delay in the start of a
>> sound relative to the time I activate it.  I don't hear a delay with either
>> setting.  
>
> Did you try to route the original sound together with the gizmoed one to the
> output? For me that illustrates the latency best.
>
> The only alternative I know is granular synthesis, which has no latency. But
> as far as I know no one succeeded to make a real-time granular synthesis patch
> in max that -doesn't- have artifacts for a fair shifting/stretching range,
> like for example Ableton Live.
>
> Mattijs

Cheers for the replies! They've given me a bit more insight into the whole time stretching deal. I also tried out the phase vocoding. I haven't tried it fully, but how would around 6-7 of those work with the frame size set at 1024 samples and overlap at, say, 4, like in the nice patch up on the cycling website? Am I asking for a crashing program there?

> Am I asking for a crashing program there?

time stretching, yet again