DSP Module: Convolution + leading zeroes



I’m trying to get convolution working as in the DSP plugin demo but I’m having a problem with the loaded impulse responses.

I load two different impulse responses. One of the impulse responses a simple delay: 512 zeros, an impulse and 512 more zeroes. The other is an IR with length 1025 samples and Tukey windowing. I’m loading them using convolution.loadImpulseResponse(BinaryData::delayFIR_wav, BinaryData::delayFIR_wavSize, false, maxSize);

The problem is, when I pass an impulse through the VST plugin, the signal from the first impulse (the delay) isn’t delayed and second impulse is shifted slightly early. It seems like all my leading zeros are being removed somewhere (for compression?).
If I set the first sample in both .wav IRs to 1.0 then I don’t have a problem, the IR goes from the beginning.

Is there something I’m missing and I can switch off whatever compression is happening when the IRs are loaded?

Also, there is a gain scaling happening as well, but I will tackle that once I get the full IRs to load properly…

Thanks in advance!

EDIT: I’ve just found the trimAndResampleImpulseResponse() function in juce_Convolution.cpp. This seems to be the culprit. Unfortunately, there doesn’t appear to be any way to bypass this without me patching JUCE. Any one know any other methods for getting the full impulse response loaded?


Hello ! I’ll probably add an option to make the trimming optional next week :wink:


Great! Thanks!

For now, setting the first and last samples to just greater than the -80dB threshold should stop it, but it’s always nicer not to have to add “noise” to the impulse response :slight_smile:


@IvanC I’ve been looking through this again and noticed that the IR is also normalised. Will it also be possible to avoid this? Ideally there would be an option to use the unprocessed IRs. For now my workaround is to add a sample at the start and end that avoid the trimming and calculating the normalisation coefficient independently and applying the inverse.