Stretch v2

[bgold-cosmos]

Update of #149

[bgold-cosmos]

One comment on this is that the timestretch algorithm used here doesn't really work with the workaround for issue #196. So if you're timestretching long samples, it may sound weird, but I'm not sure when it becomes noticeable since the timestretching itself is going to sound weird.

[yaxu]

I'm just trying to getting this running, I think it's just the timescale parameter that needs sending, right?

Maybe we could call that parameter stretch instead? Tidal already has a function with that name, but it seems to only be a supporting function for fit'.

[yaxu]

I've got it working now, sounding nice and gnarly! It would be nice to have a version that resizes it relative to the event duration (the delta param). Not sure what that could be called, maybe pack?

[bgold-cosmos]

The parameter was originally called stretch and I can see in the commit history when it changed, but I don't remember at all the reason why. I have a vague recollection of some discussion about possible name collisions in SuperCollider.

By your second comment, you mean a version that automatically stretches the sample so that it fills the event duration?

[yaxu]

Ah OK, maybe @telephon remembers about the name collision. We could still call the parameter stretch on the tidal side, although it's nice to have things named the same everywhere.

And yes that's right. A bit like legato. In fact it could detect if legato is switched on, and if so change its behaviour so that the eventual duration in seconds is legato * stretch * delta.

[telephon]

The parameter stretch is used in the event system of sclang for a different purpose, so we might want to avoid it.

[telephon]

How should these parameters work for synths?

[yaxu]

Perhaps we call it timestretch then, with the alias stretch in tidal.

For synths I guess we'd just multiply legato up using stretch and not use it otherwise? As synths are already stretchy by nature.

[telephon]

For synths I guess we'd just multiply legato up using stretch and not use it otherwise? As synths are already stretchy by nature.

yes. synths may still use the timestretch argument if they like, to add some inexplainably weird distortion :)

[yaxu]

Oh I hadn't realised that synths could actually be timestretched with the same effect! That's strange
edit Oh re-reading I think I misunderstood. You're saying individual synths can add timestretch distortion? Heh

[telephon]

You're saying individual synths can add timestretch distortion? Heh

yes, they could do anything with that parameter, so that when you mix synths and samples in one pattern, they have some sort of analogy to each other.

[telephon]

just a few things, I think nothing complicated …

[telephon]

Thank you! Just some minor things …

[telephon]

1. you are clipping the value here, but in line 124 you are using it unclipped. Won't this lead to problems? Also in the line if (~timescale.notNil) { sustain = sustain * ~timescale }; above, you are using the full sustain, while in the synthdef you are clipping it, while the sustain is still the same length.
2. Further down, there is a line:

windowIndex = phase - (phase.div(timescaleStep) - [1.0, 0.0] * timescaleStep);

Are you sure this is correct? Note that there is no operator precedence in supercollider. I'm unsure right now.

[bgold-cosmos]

windowSize and timescale can be varied completely independently and the algorithm still works, but may sound odd for certain combinations. I'm really clipping on windowSize values, but a "good" windowSize tends to scale somewhat with the length of the effect. I'm not sure what you mean about the sustain.

The windowIndex calculation is correct, but unnecessarily obscure. I added a variable to clarify it a bit (and it might save a repeated computation).

[telephon]

I'm not sure what you mean about the sustain.

Let's say e.g. you are setting # timescale 0.09 for a sample that is 1 second long. Then your playback synth will have a total duration (=sustain) of 0.09 seconds. But your window will be (0.1 * 0.05). Or, when you set # timescale 3, your synth will be 3 seconds, but the window will be (2 * 0.05). But also, in line 124 (timescaleStep = windowSize / timescale; e.g. for a very large timescale, the timescalestep will be very small, but the window won't get smaller because of the clipping.

I am not sure if all that is a problem, it just looks like a source of hard to trace errors. It might be easier to reason about when you limit the stretching before everything else?

[telephon]

Sorry to have left this dangling. I meant that because timescaleStep is clipped, the overlaps will become larger when timescale < 0.1. Could you check if that is really correct? If that is what you want, it might be good to make a comment.

[bgold-cosmos]

I'll take a look! I have since noticed that a combo of frequency shift (fshift) and speed modification works pretty well for smaller amounts of stretching.

[telephon]

Let me know if you want to add more polish.