DelayLine prepare - set/change totalSize

Feature Requests
1

The dsp::DelayLine lets us set the maximumDelayInSamples (totalSize) in the constructor – and the DelayLine buffer size is only changed in DelayLine::prepare()… so why can’t we have a parameter in DelayLine::prepare() to also change the maximumDelayInSamples (totalSize) based on the samplerate in prepareToPlay()? That would save us having to allocate a larger size for 192kHz in a 44.1kHz session.

Thanks,

Rail

2

prepareToPlay is always called when the sampleRate changes. so you just put that prepare in it, followed by setting the max delay in samples. in order to make it sampleRate dependant, just multiply sampleRate with some value and put the result into the delay, like sampleRate * .001 for 1ms

3

I think you need to check out the dsp::DelayLine source code.

If it were that simple I wouldn’t have made the FR.

the variable totalSize is set in the constructor and never changed again…


dsp::DelayLine<float, juce::dsp::DelayLineInterpolationTypes::None>  m_BypassDelayLine { 1198 };        // Set to max delay for highest sample rate (192kHz)

…

DelayLine<SampleType, InterpolationType>::DelayLine (int maximumDelayInSamples)
{
    jassert (maximumDelayInSamples >= 0);

    totalSize = jmax (4, maximumDelayInSamples + 1);
    sampleRate = 44100.0;
}

and in prepareToPlay() when you get to change the sampleRate… you call:

        juce::dsp::ProcessSpec spec;
        spec.sampleRate = m_dSampleRate;
        spec.maximumBlockSize = m_iSamplesPerBlock;
        spec.numChannels = iNumberOfChannels;
        
        m_BypassDelayLine.prepare (spec);

as I said, the DelayLine::prepare() sets the bufferSize…

void DelayLine<SampleType, InterpolationType>::prepare (const ProcessSpec& spec)
{
    jassert (spec.numChannels > 0);

    bufferData.setSize ((int) spec.numChannels, totalSize, false, false, true);

    writePos.resize (spec.numChannels);
    readPos.resize  (spec.numChannels);

    v.resize (spec.numChannels);
    sampleRate = spec.sampleRate;

    reset();
}

Unfortunately there’s no way to set the totalSize to match the sample rate - so we waste memory at lower than 192kHz.

Rail

4

Maybe the idea was to stop people from accidentally allocating memory on the audiothread?

5

prepare() is already allocating memory so doubt that’s it

Rail

6

a workaround is to recreate your delayline in prepare() according to the new max size when needed (i.e when it increases):

delayLine = std::make_unique<juce::dsp::DelayLine<float, juce::dsp::DelayLineInterpolationTypes::None>> (maxDelayInSamples);

On a side note a method to get the current max size would be useful (there’s an other FR here about that)

1 Like
7

Yeah I know… but I’d prefer if the class were changed :slight_smile:

Thanks,

Rail

8

oh yeah, sry i really didn’t know JUCE’ implementation myself. i didn’t even consider it to not be able to change its ring buffer’s size lol. but hey, if you know what the problem is just roll your own. only takes a few minutes anyway

9

I think the workarounds are well known.

  • a unique_ptr is not an option in a ProcessorChain
  • rolling your own is not the idea of a framework plus it locks you off from future improvements of the class

So I guess either there is a technical reason we fail to see why it is not possible, or it is just a little omission that is easily fixed…

Would support but am out of votes :slight_smile:

2 Likes
10

Thanks for your patience. It is now possible to set a new maximum delay time after construction of the DelayLine:

I’m closing this thread to free spent votes.

2 Likes