DSP module version 2 (preview)

It’s here, it’s here, it’s here

Well some classes we have been working on are still being refactored at the moment, but most of them are already there, in the juce6 branch from the new JUCE github repository :wink:

I’ll talk about them in details when I have some time. Here are the names of the new classes:


  • BallisticsFilter (for envelope detection and visualisation algorithms)
  • DelayLine
  • DryWetMixer
  • FirstOrderTPTFilter (first order or 6 dB/oct filters with the TPT structure)
  • LinkwitzRileyFilter (for multi-band separation filters)
  • Panner
  • StateVariableTPTFilter (basically the same than StateVariableFilter but with another API)

widgets (basic but effective algorithms)

  • Chorus
  • Compressor
  • Limiter
  • NoiseGate
  • Phaser


  • ZeroOrderHoldInterpolator
  • LinearInterpolator
  • WindowedSincInterpolator (using a look-up table for high precision interpolation)

Other classes have been reworked or updated (Oversampling, LadderFilter, FFT, MemoryAudioSource, LagrangeInterpolator etc.), and we are also planning an update on Convolution.

Have a look at them and tell us already what you think about those additions


Looks good to me :slight_smile:
I think the source code makes it possible for developers to modify or enhance functionality if they choose. Glad you didn’t over-engineer here.

It also gives those of use who already have a good sense of the audio processing side a great example of a solid c++ implementation. I have my own implementations of several of these modules and it’s nice to compare code!

1 Like

I am looking forward to looking through these in more detail but it looks like I can retire a few of my own classes!

For the Convolution class update it would be good if the amount of memory it allocates can be set in the constructor, just like the new Delay. This will make it more appropriate for multichannel use with high channel counts.

1 Like

Pretty exciting!

I’m just starting to build more sophisticated ProcessorChains and it’s been useful to read and crib tricks from the existing dsp examples.

One minor thought: it might be useful to have a bit of docs on options such as the available panning rules.

This is a nice leap foward!

1 Like

@IvanC, I’ve spotted a bug: BallisticsFilter has
SampleType BallisticsFilter<SampleType>::processSample (int channel, SampleType inputValue), but process() is calling it with the arguments in the wrong order:
outputSamples[i] = processSample (inputSamples[i], (int) channel);


Thanks for all your feedback !

Hey Ivan!

Just starting to dig into the new changes, and they look great!!

A small request: in the DelayLine class, it would be nice to be able to have a set() function, to go along with the push() and pop() functions, that would allow you to set a value anywhere in the delay line. This can be pretty useful for doing waveguide stuff.

Also, this might only be useful for a certain project I’m currently working on, but I like to have a separate updateReadPointer() function, that could be called separately from popSample(). Anyway, I’m sure you’ll make the right call as to whether that might be needed enough generally to merit being implemented.

Thanks for all your great work!

Hello and thanks for your comments !

Well I think this class is already more than your common delay line class, with all the available customisation capabilities (the setDelay function, all the interpolation algorithms, the updateReadPointer boolean etc.). And still @t0m and I thought it is already too much :slight_smile:

So what I can tell you is that we don’t want to fix the API once and for all now, and the rule in general for the addition suggestions to make it in the API is to do it if enough people ask them.

That makes sense (plus it’s not too hard to extend the class for even more customisation). Thanks for considering it!

1 Like

The dsp::Convolution has been updated to add some features and fix some issues with realtime safety. Now, the Convolution will allocate impulse response storage as necessary, on a background thread, which means that memory usage for short IRs should be lower.

1 Like

Thanks! I am looking forward to checking this out!

1 Like