Timestretching/Pitchshifting

[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.

[d.healey]

@Christoph-Hart Was it RubberBand 2 or 3 that you tried?

[Christoph Hart]

@d-healey Both. Rubberband v2 sounds completely off and Rubberband 3 sounds about as good as signalsmith (on some signal's it's better on some worse), but has 3x the CPU usage plus I couldn't get it to work correctly with the start of a sample (the API works a bit different so I would have to account for that).

There are a lot of parameters you can tweak in Rubberband so I might have just used the wrong ones, but I just wanted to slap it in and compare it to signalsmith and for my taste signalsmith is the clear winner here.

[johnmike]

so I have multiple drum loops loaded across multiple keys...Stretching works fine when I play a single key...but when I play multiple keys at the same time it plays back the loops at different BPMS..one key seems to hold the stretched tempo while the other is playing back at the original BPM that the loop was recorded at...

[johnmike]

as an addendum to the previous...seems as if the loops are the same bpm(originally before bringing in) then they play just fine when played together...but if they are different tempos(originally) they won't play back at the temposynced BPM....hopefully this makes sense....is there something I'm missing? or do all the loops I add in need to be at the same BPM for them to work together?

[Lindon]

@johnmike said in Timestretching/Pitchshifting:

as an addendum to the previous...seems as if the loops are the same bpm(originally before bringing in) then they play just fine when played together...but if they are different tempos(originally) they won't play back at the temposynced BPM....hopefully this makes sense....is there something I'm missing? or do all the loops I add in need to be at the same BPM for them to work together?

So my understanding is that the time/pitch stretching is applied to the sampler - and it is applied as a ratio - so yes if you want to play multiple loops together - everything in the sampler needs t start out at the same tempo - or you can set up sample maps with a single loop in it - and then use multiple samplers..

[johnmike]

@Lindon Gotcha...that's what started to make sense...not a problem...that means I just need to time stretch all the stuff that I want to time stretch into the same tempo lol...I'll mess about with that!

[d.healey]

@johnmike What about using multiple samplers, does that work?

[johnmike]

@d-healey I’m sure that would work…but for what I’m trying to do I’d need 88 samplers lol(a sampler for each loop on each key)…it would probably be way more efficient and less time consuming for me to just make everything a uniform BPM and then put them in one sampler…

[Christoph Hart]

no, the idea is that the tempo_sync mode will sync each sample to the BPM regardless of its source BPM, but this mode isn't working correctly yet. I'm totally undecided how to address the issue of detecting the bar length and getting the right multiplier so if anyone has ideas how to do this, let me know.

[johnmike]

@Christoph-Hart ahh gotcha…yea that would work…but as it stands this is still way ahead of where we were! I’ve been waiting for this!

[Lindon]

@Christoph-Hart said in Timestretching/Pitchshifting:

no, the idea is that the tempo_sync mode will sync each sample to the BPM regardless of its source BPM, but this mode isn't working correctly yet. I'm totally undecided how to address the issue of detecting the bar length and getting the right multiplier so if anyone has ideas how to do this, let me know.

Yep - you could do it like Kontakt(yew did I just say that?) - have a scripted call that lets the programmer/developer tell the process exactly how long in bars/beats each loop is and what tempo it is

[Christoph Hart]

@Lindon Why not just make a new sample property called NumQuarters that will be used to calculate the original BPM of the sample?

This will override the NumQuarters that you can set with the timestretch properties, which will override the default fallback behaviour of guessing how fast it is using the current tempo.