Onset-guided time stretching

Is anyone aware of a Quark or other SC example of time-stretching a buffer, without (or optionally) changing the pitch, using a list of onsets? For example, with “Acidized” or REX loops, there are a series of markers giving “good places” to break/synchronize a loop. (I’m assuming you’ve already processed your buffer, or done it manually, to figure out these onsets.)

It’s similar to granular synthesis, I guess, except using that extra timing information to ensure you have crisp onsets of percussive sounds (not just moving continuously through the buffer with grains).

I’m aware of the PaulStretch stuff (e.g. Sam Pluta’s very cool TimeStretch Quark), but those are more for melodic or textural sounds, and for stretching by a large amount, like 50x. And of course the excellent Élastique stuff that most software seems to license to do time-stretching. But is there a “poor person’s” version in SC that can sound half decent?


Have you tried Warp1?

Yes, that’s basically what I want and works pretty well if you find the right window size for your loop, but ideally it would also use the onsets information I provide (via another buffer?). The way it is, on percussive loops, you tend to get “flangey” effects due to the grains, especially as they pass over sharp onsets. Anyhow, it’s still pretty cool…thanks for the reminder.

You could control the time pointer with an EnvGen with Warp1, so you can program your onsets there.if your Env moves through 0.2 seconds of time in 0.2 seconds, you get no stretch, so you can make your time pointer as complex as you want with your onset information.
Hope that helps

Josh Parmenter

Yeah, thanks, I’ll have to experiment with that. I don’t have it totally clear yet what I’d want to do, and test whether Warp1 would still “smear” the sound when running at regular (1:1) speed.

I guess I’d have to make the time pointer run faster between onsets, but within a window around the onset, run at regular speed. Or something like that…and ensuring the overall time is the stretched duration I want… Sounds easy. (-;

You can do phase vocoded time stretching with the BufFFT plugins. Many examples in there. Elastique is just a phase vocoded time stretch…but a very good one. A “poor-man’s” approach would probably be to use Reaper, which uses Elastique, to stretch the audio. Nice video on that here.

Let me know if you need a windows build of BufFFT. I could build that and upload it to the release.

Just think ‘outloud’…

…I wonder if using the onset detection to fade between different Warp1 instances with different window sizes would work? That way you might be able to use a smaller window at the onset and a larger one throughout.

This would work in real time, but if you only needed it offline, then ness–stretch is pretty good!

Yes, thanks @Sam_Pluta, if you don’t mind making a Windows build of BufFFT, I’d love to play with it! Sorry for the delay in replying… I didn’t realize there was this NessStretch refinement to PaulStretch (I used your earlier TimeStretch quark that did something like PaulStretch in real-time, and off-line, and really enjoyed it).

Thanks @jordan, that’s an interesting idea – I’ll have to try that, and see if it’s jarring to move between the two versions with different window sizes. At least this way I wouldn’t have to try to figure out how to move the time cursor at different speeds.

I uploaded a build that doesn’t have the ness_stretch. Everything else seems to work.

I can’t get the rust library to link on windows, but I’ll work on it. If anyone has any experience linking a rust static library on windows, I’d love some help. It is complaining about ‘dl.lib’ and ‘pthread.lib’.

ness_stretch works great on the command line: GitHub - spluta/ness_stretch


1 Like

Those are libraries for POSIX functionalities (dynamic library loading and OS thread operations respectively). I had a look through the code and I think for your windows build you can just remove those from your link libraries (BufFFT/CMakeLists.txt at main · spluta/BufFFT · GitHub). I think on Windows the C++ runtime itself has all that (i.e., you don’t need to link against any additional libraries) but I might be wrong.