Float* AudioParameterFloat::getValue()? plus empirical justification


Memory is cheaper and larger, but CPU speeds have stagnated. Calculating cross fades between automation data is CPU intensive and unnecessarily repeated every cycle. Is it possible to access process blocks sized arrays of automated sample accurate parameters where the DAW has that info available?
This would code really simply with the new DSP classes. Ivan and Fabian you have done an amazing job on the DSP module. I think we will be processing in blocks of data for many decades to come, that is until we get Quantum computers.


It’s not possible at the moment. JUCE only delivers one automation value for the parameters per processBlock call at the moment, no matter what plugin format and host you are using. Hopefully they will implement something for VST3, for example, at some point.


Thank you.
Proper gain smoothing should probably be some form of filter or interpolation, but there is no way this is feasible every cycle of processBlock.


Here is an interesting case study from an EQ manufacturer.

“To find out what kind of artifacts are produced by current plugins on the market, we fed a pure 1 kHz tone into a number of popular EQ’s while they were being automated.[2] To be “nice,” we didn’t attempt to automate things like toggle controls that we already know produce full-scale clicks & pops in other companies’ plugins — we just stuck to continuous controls like sliders and knobs.”

And here are there results from October 2, 2015

EQ Plugin Distortion / Artifacts
Goodhertz Tiltshift -114 dB
DMG EQuilibrium -65 dB
FabFilter Pro-Q 2 -60 dB
Brainworx bx_digital V2 -53 dB
Brainworx bx_cleansweep V2 -52 dB
Logic X Channel EQ -51 dB
iZotope Ozone 6 (Analog) -47 dB
Waves H-EQ -41 dB
iZotope Ozone 6 (Digital) -34 dB

These old results show how important smoothing and accuracy of automation can be. When changing gain we are modulating our output with an audio signal(ie the automated gain curve). This curve should not contain aliasing or kinks and that should be an offline burden handled by the DAWs and eventually supported by JUCE. That said JUCE is amazing…


I can’t see why there would be a difference though in CPU load though? At some point, someone needs to calculate the automation position for each sample, whether that’s the host or your plugin.

To get super smooth automation you still need to update your calculation parameters extremely frequently.

The only real difference between the block based automation and the VST3 sample-accurate automation is that you get a more accurate automation position. The movement of parameters etc. which will take CPU and possibly introduce Distortion / Artifacts still needs to be handled by the plugins themselves. You’d still have to do parameter smoothing in this case to avoid artefacts from sudden jumps in the parameter automation etc.


Hi Dave,
I was dreaming of the day when we multiply sample accurate blocks of gain automation data by the blocks of audio in the plugin, but where the automation has been optionally filtered as it has been recorded by the DAW. Then when the DAW is idle alternate higher resolution filtering could be applied. Automation smoothing only need be applied once when handled by the DAW like an audio track, but on every pass when handled by a plugin. Multiplying by a block of data is not anywhere near as CPU intensive as upsampling with a DSP::filterHalfBandPolyphaseIIR or the like at possibly obscure intervals.
DAWs are always trying to differentiate. Optional automation anti-alias may just be a sales gimmick to convince mastering engineers to buy one DAW over another.
You guys do an amazing job and us users will always ask for more. We do trust your timing and judgement. I was opening up a discussion as I implement automation smoothing and I hope I have not discouraged you guys from your amazing work.


I’m not sure I quite follow…

Sample accurate automation in VST3 doesn’t give you a float buffer of all automation values for a block, indeed this wouldn’t be the most efficient way to do it because it would involve us (the DAW) filling this buffer for every parameter, for every block.

As far as I can remember, VST3 gives you an effective “curve” for the block which you (the plugin) can then use as you see fit, either interpolating values from it or ignoring it and doing your own block, based updates.

I guess the real difference is that the VST3 approach puts the responsibility on the plugin to update parameters, rather than the host.

In Waveform we split hardware sized blocks up in to smaller chunks based on the level of detail in the automation curve. This means plugins don’t have to worry about anything apart from making sure any responses they perform in relation to parameter changes (such as updating filter coefficients etc.) don’t cause distortion/artefacts.

I guess it boils down to a question of how much work you want to put in as a plugin developer to update your own parameters to gain some increased accuracy vs how much you don’t want to have to worry about that.

Seeing as you’ll likely to have to do some of your own internal smoothing anyway I can’t see a huge advantage in getting sample-accurate automation.


I think these two contradict each other effectively. Sample accurate automation creates the artefacts, that the plugin has to iron out using parameter smoothing (i.e. also limiting the changes in some parameters depending on their meaning). In gain parameters usually you ramp your factor, vs. in filters, the frequency must not change faster than a certain amount to not produce artefacts.


Thank you this is news to me and now I understand why the plugin developer must handle the automation smoothing. I had hoped they would only provide it when automation has been used, not for every case and at a highest resolution (which would chew up disk space).
Very useful info.
Thanks for your time.