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
I’ll talk about them in details when I have some time. Here are the names of the new classes:
processors
BallisticsFilter (for envelope detection and visualisation algorithms)
DelayLine
DryWetMixer
FirstOrderTPTFilter (first order or 6 dB/oct filters with the TPT structure)
StateVariableTPTFilter (basically the same than StateVariableFilter but with another API)
widgets (basic but effective algorithms)
Chorus
Compressor
Limiter
NoiseGate
Phaser
interpolators
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
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!
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.
@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);
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.
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
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.
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.