So close to Rubberband-ing

iamlamprey

Hello old friends.

I have a real-time pitch-shifter working completely in HISE using Rubberband, but unfortunately it's throwing all kinds of strange errors when it comes time to export the .VST:

ChatGPT seems to think it has something to do with the Rubberband library using #include windows.h> before the JUCE stuff, which is causing clashes.

Christoph also mentioned:

@Christoph-Hart said in Connecting Rubberband Library for use in HISE:

Just looked at their repo and it seems that they have a single .cpp file that you can add. Just include that in your node file and you should be good (you might have to adapt some Rubberband compiler flags to enable a single translation unit build).

If anyone can help me finish this one, I'll post the full writeup for it on the forum

Seth Munson

I've also been attempting to play with the rubberband library to no success so looking forward to that write up if get to that point :)

d.healey

Why not use the built in pitch-shifter?

iamlamprey

@Seth-Munson is that Seth Munson from the Chango forum?

@d-healey said in So close to Rubberband-ing:

Why not use the built in pitch-shifter?

Compiling the node results in link errors, there's also an issue with the STFT window resulting in clicking/popping, and comments like:

@Christoph-Hart said in fx.pitch_shift not working in a multi channel network:

haha don't use that, I'm probably ditching it again soon.

it‘s not really usable right now because there are some severe artifacts in the pitched signal

There's some rounding error in the sample index at the buffer boundaries which I can't track down with my limited time allocated to this feature :)

The Rubberband single file import works perfectly within HISE, it just fails to compile. I'll keep messing with it, I'm sure it has something to do with importing libraries before JUCE, resulting in ambiguous symbols, I just can't figure out where/why

iamlamprey

Progress! I have it compiling and "working" in Ableton, as long as I stick to ASIO and not MME (which means I can't record any clips just yet).

MME / Windows Audio crashes instantly.

iamlamprey

Okay so (at least) one of the issues is that RB can't process in-place or on an alias, it needs a separate input and output vector.

dyn<float> outPtrs;

template <typename T> void process(T& data)
	{
		if (!rb) return; // safety check in case the rb object isn't constructed yet

		auto ptrs = data.getRawDataPointers(); // RB needs pointers
		outPtrs.referTo(data, data.size()); // dyn confuses me		

		rb->shift(ptrs, &&outPtrs); // ??? 

		data = outPtrs;		
	}

@Christoph-Hart do you have any suggestions for creating a blank vector the same size as the one from getRawDataPointers() for RB? I assume memcpy() isn't ideal in the audio thread

iamlamprey

(laughs in thall)

Writeup soon

HISEnberg

@iamlamprey Amazing work, it sounds pretty great! Excited to test the results myself

d.healey

@iamlamprey Oh so close :) very exciting. Is it the sort of thing where it's easy to swap out one algorithm for another? I'm thinking of trying the Bungee library.

iamlamprey

@d-healey The actual DSP in the third-party node is pretty simple, the main stuff was getting all of the includes to work together (and using the right class in RB that doesn't need 2 separate buffers)

The RB time-stretching stuff might also be possible using this third-party node and just swapping a few things out, I don't want to give out false hope just yet but