Scriptnode pitch-shift a signal

[d.healey]

@Christoph-Hart Does this mean we can have a pitch LFO in effects plugins now?

[Lindon]

@Christoph-Hart well the stftPitchShift looks pretty good - and quick and has a MIT license...

[ps]

@Lindon @Christoph-Hart
stftPitchShift is def the best out there I could find - it can do polyphonic and also formant shift.
2048samples latency is normal for pitch shifting audio (it's also normal that low signals sound bad when pitch shifted in those kind of plugins)
I'd love to see that implemented as well :)

[Christoph Hart]

@ps I played around with it yesterday but it always sounded very cheap. I‘m definitely doing something wrong maybe I‘ll try their JUCE example and go from there.

[Christoph Hart]

@d-healey said in Scriptnode pitch-shift a signal:

@Christoph-Hart Does this mean we can have a pitch LFO in effects plugins now?

A pitch lfo can be made with a simple delay buffer that modulates the delay time (a basic chorus), a pitchshifter would be overkill.

[ps]

@Christoph-Hart did you align the pitch shift with the timbre shift and set a timbre frequency to around 2.5 - 3ms?

if the formants are not shifted together with the signal it will sound strange :)

[ps]

@Christoph-Hart can you point me in the direction how you included the library? i fail drastically somehow.

[Christoph Hart]

@ps I added a third party node, included all files in there and then fought an epic battle until all compile errors went away.

You need to use a replacement for std::span (I ended up with tcb::span) as this is a C++20 feature.

However I'm really not convinced about the quality here - the CPU usage is 2-3 times as high as signalsmith and the sound is super bad. The latency is a bit better, but that's really the only thing that this library has going for them.

Also the coding style is super counterintuitive - I literally had to copy the entire plugin code into the node and write a wrapper because I couldn't figure out how it expects the different buffer sizes to work.

[ps]

@Christoph-Hart can you share the node template with me? I'm doing something wrong - I get 2000% cpu even though I'm pretty confident I do the processing in buffers haha

btw in general It would be interesting to see how you write a wrapper around a juce plugin code and integrate it as node :)

[Christoph Hart]

@ps Are you using the debug build? If you don't build the release configuration it also maxes out my CPU here with a single instance.

btw in general It would be interesting to see how you write a wrapper around a juce plugin code and integrate it as node :)

Sure, here you go:

ThirdParty.zip

This is definitely not anything I'm proud of - I just want to get this thing to work so the coding style is all over the place. If this would make it into HISE it would require a almost 100% rewrite including swapping out whatever weird thing they are using for the FFT with the proper libraries (IPP / vDSP) etc, but I'm rather sceptical at the moment that it's worth the hassle.

You might have to set the USE_JUCE_PROCESSOR preprocessor to true and manually add a few JUCE modules to the DLL Projucer project (I think audio_processor & hi_streaming are missing).

[ps]

@Christoph-Hart haha thank you - I will have a completely non-judgmental look :)

[ps]

@Christoph-Hart one last thing - what is the magic trick to make it find the files referencing each other?

'../stftPitchShift-main/cpp\StftPitchShift/RFFT.h' file not found

#include "../stftPitchShift-main/cpp\StftPitchShift/RFFT.h"

[Christoph Hart]

@ps There's a backslash in the path (after cpp. Try if changint this to a normal path helps, otherwise just make sure that the relative paths from wherever you call that works.

[ps]

@Christoph-Hart ok i managed to compile it - and if this is what you have heard I understand now why you are not impressed. I downloaded the vst and tested it and it sounds pretty different and has also a completely different performance. I'll do some digging.