Frequency Shifter

[Christoph Hart]

ok, got you! So if I want create a duplicate signal with -90° phase shift I multiply by -0.5, right?

I am not a DSP expert, but the only trivial phase change that can be achieved by simple multiplication is 180° because it's just a flip of the signal. Multiplying with -0.5 will just result in a 180° phase shift plus a gain adjustment of -6dB.

Any other phase change can't be applied on a signal because there is no frequency dependant phase value, so you'll need some kind of all pass filter which does that for you.

To be honest, I've still haven't heard one frequency shifter that does not use FFT processing which doesn't sound like the last breaths of a dying robot (even the one in the STK toolkit sounds rather, well "experimental"), but if your "ring modulator" sounds good, then don't touch it :)

[clumsybear]

@Christoph-Hart said in Frequency Shifter:

Multiplying with -0.5 will just result in a 180° phase shift plus a gain adjustment of -6dB.

makes sense, I already figured out that even if I manage to flip the phase by 90° it will only change the phase of one frequency. Like you said, I'd need a Allpass filter network of some kind. That's why I rendered out a Hilbert transfer function as an IR in Matlab. It's an IR of an Allpass filter network that results in a phase flip of 90° over a 500-15000hz range with minimal error.

@Christoph-Hart said in Frequency Shifter:

To be honest, I've still haven't heard one frequency shifter that does not use FFT processing which doesn't sound like the last breaths of a dying robot (even the one in the STK toolkit sounds rather, well "experimental"), but if your "ring modulator" sounds good, then don't touch it

It only sounds ok if I put the whole node graph in a 2 frame block container and oversample the frame block container . if not there are too many artefacts.

So the issue right now is that Im not able to run an IR within the frame block container. If they are in separate frame blocks, the result is terrible.

[Christoph Hart]

How long is that impulse response?

You might get away with brute-force convolution (just a normal FIR filter) if the tap size is below 64.

[clumsybear]

It's 1024 samples long and generated at 44100 SR. I'm not sure about the tap size, is it the same as the length in samples?

[Christoph Hart]

Yes, well that may be too long and if you oversample this to run per sample, it will definitely burn your CPU (since you can't do FFT based convolution with one sample and have to resort to brute-force time-domain convolution).

I don't know too much about FIR filter design, but if you take a look at the 1024 sample IR, is there any substantial (non-zero) value after ~64 samples? Because if not you can truncate it to 64 samples (which is the break-even point where the FFT based convolution will yield better performance) and check how it sounds.

[clumsybear]

I had a read on that topic, and it seems to work with exactly 64 samples as well. I'll try to render out a smaller version or truncate it.

Can you elaborate on the brute force convolution technique wit FIR filter in HISE? I'm not entirely sure what you're referring to.

[Christoph Hart]

The current convolution module is doing the convolution on the frequency domain, but for smaller impulse responses (as I said, up to 64 samples), directly convoluting each sample is more efficient (and in our case, also possible on per-sample level). The pseudo code algorithm for this looks like something like this (it's not the actual formula, but the complexity is similar:

for(int i = 0; i < blockSize; i++)
{
    for(int j = 0; j < irSize; j++)
    {
        output[i] += output[i - j] * ir[j] ;
    }
}

As you can see, it has to iterate over the IR size for each sample so for bigger impulse responses the CPU power goes up exponentially.

I think I will add a filter.fir module that you can use instead of the convolution module, which will do this and work in a frame container.

[Christoph Hart]

Actually I just need to wrap this JUCE class, which does it already :)

[clumsybear]

Damn, that sounds promising man! :) Thanks for clarifying

[clumsybear]

@Christoph-Hart Did you happen to find time to implement the FIR module?

[Christoph Hart]

No not, yet, but maybe I find the time today.

[Christoph Hart]

There you go:

https://github.com/christophhart/HISE/commit/53cadb918f4c4e32e83387e32973b7c3a14a6b42

It's basically a convolution reverb that can be applied in polyphonic contexts and frame processing. Since it's brute force convolution in the time domain it caps the impulse response at 128 samples, otherwise the CPU would explode if you try to feed it with a big impulse.

[clumsybear]

@Christoph-Hart said in Frequency Shifter:

It's basically a convolution reverb that can be applied in polyphonic contexts and frame processing. Since it's brute force convolution in the time domain it caps the impulse response at 128 samples, otherwise the CPU would explode if you try to feed it with a big impulse.

Thank you, I'll give it a try :)

[clumsybear]

@Christoph-Hart the FIR works with IRs at 128 samples.
I have to figure out how much latency in ms a 128 sample long IR generates at different sample rates and I'm good to go with my massively CPU heavy frequency shifter :D

Is there a sample based delay in scriptnode?