Hello! I’m using the juce oversampling module for a plugin I’m working on, but I’m having an issue with the low end being cut pretty audibly. The plugin I’m working on is intended for electric bass so keeping the low end is ideal! I’m wondering if I’ve set up my constructor wrong or something. Anybody have any insights into this issue?
surprised that nobody answers here, not an expert for the juce oversampling, but last time I checked it, it worked very well.
But I didn’t use addOversamplingStage, just used the default constructor, but with integer latency option.
Also do you mind the latency the class induces, if you don’t compensate you might end unintentionally up some comb-filter effect, if you mix it with the dry signal.
maybe someone with more experience can jump in here
(in addition, you should always measure, not just listen, that alone can help)
@moritzsur last time I check r8brain, it was not really usable for realtime inline over and downsampling, can you tell me whats wrong with the juce implementation for this special case
If you set up and use the oversampling correctly, you should not hear a low cut. Just load your plugin into Plugindoctor with oversampling only. Here is what I got:
I haven’t used addOversamplingStage before. If you want different oversampling rates, try this:
for (size_t i = 0; i < numSamplers; ++i) {
overSamplers[i] = std::make_unique<juce::dsp::Oversampling<FloatType >>(
spec.numChannels, i,
juce::dsp::Oversampling<FloatType>::filterHalfBandFIREquiripple, true,
true);
overSamplers[i]->initProcessing(spec.maximumBlockSize);
I would suggest using useIntegerLatency=true to make your life easier (setLatencySamples only accepts integers!). And don’t forget to report the latency after changing oversampling rates.
You should also pay attention to the processSamplesUp and processSamplesDown. See the discussion here