Today, if you want to store/read/process an array of samples (say float), you have a lot of possibilities to do so in JUCE :
- some InputStream / OutputStream classes
- and now the AudioBlock class !
And we shouldn’t forget the float or std::vector / std::array classes as well… Confusing isn’t it ?
So what do we do if we want to manipulate audio samples in JUCE for general purposes tasks ? For example in a plug-in, where we need to do stuff like processing incoming samples, storing some samples for additional processing ?
In general, I tended to use mostly the AudioBuffer class (or the AudioSampleBuffer which is just the float templated version of AudioBuffer). Its API / interface makes clear that it is a better candidate for audio samples than the Array class, and something I discovered recently, you get the alignement of your data for SIMD processing as a bonus, making it useful for storing state variables or filter coefficients for example as well.
But when I made a new processing class, I generally needed to provide a process function somewhere. That’s where I got some headaches before the release of the DSP module. What should I provide there as argument to get a reference to my audio samples ? An array of floats ? The number of samples ? Multiple arrays of floats ? An array of array of floats ? How do we take multi channel processing into account ? How do we process multiple sub blocks of the main audio buffer ?
These questions were some of the fundamental ones the JUCE team asked itself during the development of the DSP module. And the new class AudioBlock was one of the answers, mainly the work of Fabian and Jules.
Now, thanks to the AudioBlock class, it is possible to provide one single object as an argument in process functions, with a reference to audio data without any extra memory allocation, providing a number of channels information + an index for the sample we want to process first. The AudioBuffer class can still be used for storing the actual data. Then some AudioBlocks can be created, made from the buffer and some subBlock functions locally. It’s also very useful if you want to process your data in small chunks whatever the size of the input audio buffer.
That’s why most of the new classes in the DSP module use extensively AudioBlocks, and that’s what the JUCE team is going to do mostly in the future developements I guess. A lot of things were easier for me to code (in the Oversampling class for example) thanks to the AudioBlock class.
What do you think of this new class ?