YAPTSA - Yet another Pitch./Time stretching Algo.

[d.healey]

The current algorithm is good but for realtime use the lag/CPU tradeoff is too great. If bungee can offer better real time performance I'm all for it. Even if the quality is lower because we can always switch to the laggy high quality algorithm for offline export.

[Lindon]

@d-healey said in YAPTSA - Yet another Pitch./Time stretching Algo.:

The current algorithm is good but for realtime use the lag/CPU tradeoff is too great. If bungee can offer better real time performance I'm all for it. Even if the quality is lower because we can always switch to the laggy high quality algorithm for offline export.

by real-time you mean changing on the fly as its running right?

[aaronventure]

Bungee sounds pretty good at 0.5x.

Falls apart, but not as much as others, at 0.25x but damn, Bungee Pro manages to preserve the transients even when slowed down that much.

[d.healey]

@Lindon said in YAPTSA - Yet another Pitch./Time stretching Algo.:

real-time you mean changing on the fly as its running right?

Not even that. I mean being able to set a stretch value and play your instrument via MIDI without either enormous lag or stupid high CPU.

[Lindon]

@d-healey bummer - i thought we had timestretching and pitch shifting in HISE now...

[orange]

For FX plugins, real time performance is very important too.

Even if the quality is lower, if the delay in real time is very low and the CPU is low, I'm in.

[Christoph Hart]

@d-healey I'd rather try to find a solution for the initial CPU spike problem than put in another library into the HISE codebase - Bungee (non)-Pro sounds OKish, but the way that the voices are handled currently in HISE, it will cause the exact same CPU spike as the current signalsmith library. Also there's no information about how much the Pro license costs (just like it was with HISE for the first 8 years lol now I get why nobody is using it).

The problem is that it has to process ~50ms of samples before the timestretcher gets some output, so I have to do this all within the first audio buffer, which causes the spike. If somebody has a smarter idea of how to solve that I'm all ears, but it has to be dynamic to be able to cope with tempo changes / modulation values.

Maybe I'll open a github issue in the signal smith library, maybe the author has an idea how to solve that.

[aaronventure]

@Christoph-Hart said in YAPTSA - Yet another Pitch./Time stretching Algo.:

spike

Can you just skip the first 50ms when it comes to timestretching and ease into it?

[d.healey]

@aaronventure Then we get latency

[aaronventure]

@d-healey I meant ease into the processing, i.e. do less timestretching in that initial period, or ramp it up gradually to spread the CPU load and reduce the spike.

For most recorded samples, ~50ms is still attack time. For percussive or faster instruments, ideally you're not messing up the transient so this could help.

[Christoph Hart]

@aaronventure could mess with the tempo syncing of loops but it might be worth a try. I think the latency is independent from the actual pitch factor (so that even at 1.0 it requires some preprocessing) but I check again.

[DanH]

@Christoph-Hart Did you make any progress with this? Was hoping to have time stretching in my next update. Currently I'm experiencing clicks at the front of a sample when playing notes and all through changing pitch with either mod wheel or modulation. Will do some more testing though.