Frequency Shifter

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

- added filter.fir node · christophhart/HISE@53cadb9

The open source framework for sample based instruments - - added filter.fir node · christophhart/HISE@53cadb9

GitHub (github.com)

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?