Timestretching/Pitchshifting

[audiolyf]

@d-healey Pulled the branch yesterday and everything else is there but I'm getting function not found both with getSampler and getChildSynth

[d.healey]

@audiolyf Maybe you pulled before Christoph added it?

[Lindon]

@d-healey said in Timestretching/Pitchshifting:

@Lindon Need to update your VI thread :)

Done!

[d.healey]

@ABYSS_CO said in Timestretching/Pitchshifting:

Don't you think @d-healey that it would be interesting to offer a tutorial on your YouTube channel to explain how to properly implement time stretching?

Definitely, once it's a little more mature.

[Christoph Hart]

@d-healey there‘s not much to show in a tutorial - just turn on timestretching and set the ratio…

[d.healey]

@Christoph-Hart I think they'll want to know how to use the scripting functions and implement a UI.

[audiolyf]

@Christoph-Hart Sample start mod is not possible, right?

[Christoph Hart]

@audiolyf Actually I just have forgot to take that into account but that's fixed now (along with a lower stretch limit of 0.0625 instead of 0.5).

[audiolyf]

@Christoph-Hart mf king!

[Christoph Hart]

I'm thinking about adding this to the AudioLooper too (it's pretty obvious that this might be useful there). Is anybody using the tempo synced mode in a real project? It previously changed the pitch to match the tempo but I guess that is so totally useless that I can replace the functionality and enable timestretching by default when the tempo syncing is activated.

[d.healey]

@Christoph-Hart

Is anybody using the tempo synced mode in a real project?

Yes, and I added new modes for longer loops (I think you merged this already). But real time stretching will be so much better.

However the main limitation of the loop player is that you can't edit the loop points. So I've switched over to the sampler with custom import now. The only problem there is every time I change a parameter the loading callback gets triggered.

[parabuh]

It would be greate if we could use time stretch for FX and slowdown incoming signal :)

[d.healey]

@parabuh You can can't do this with scriptnode core.stretch_player

[Christoph Hart]

No the stretch_player still requires an audio file. The problem is that there is a latency of 50-100ms which makes it unsuitable for realtime processing of the audio input.

[d.healey]

Noticed a strange UI glitch, xfade table is missing.

[modularsamples]

I've just tested stretch_player and the results are really, really good. At least with drums/synthy loops. Spent 10 mins just messing with an amen break, such fun.

Just a thought, wouldn't it make more sense to integrate the stretching into file_player as an additional playback mode?

[Christoph Hart]

@modularsamples no the file_player is too complex now already, if you want to switch between those you can just use two nodes and a soft bypass template, then assign them to the same audiofile slot.

[modularsamples]

@Christoph-Hart Fair enough, that would be a reasonable approach. I'm looking at from the opposite angle, merging them would make the overall network less complex.

[d.healey]

Just saw the new commits

#ifndef HISE_ENABLE_RUBBERBAND
#define HISE_ENABLE_RUBBERBAND 0
#endif

So is rubber band implemented already or is that the "theoretical support"?

[Christoph Hart]

@d-healey I've added Rubberband and played around with it but there were many glitches and the CPU usage also was much higher than with the other one while the sound-quality wasn't much better so my motivation to make this work kind of evaporated pretty fast. I decided to leave the code in there for future endeavours (or if somebody wants to add elastique on their own), but for now the signalsmith engine is where the party's at.