In audio-recording parlance, automation refers to the ability of a recording system (traditionally a mixing console, more recently a DAW) to record, and subsequently reproduce, real-time adjustments to parameters such as track volume. In DAW systems, automation extends to cover real-time parameters of plug-ins (e.g. synthesizers and signal processors). To make this work, both DAW and plugin must support bi-directional communication of parameter values, i.e.,
Automation vs. saving/restoring plugin state: DAWs and plugins also use an unrelated non-real-time method of bi-directional communication scheme, to allow the DAW to save the entire state of each plugin as part of a recording project file, in order to later restore that state when the file is reopened for a later editing session. Although this is separate from automation, I consider this an important aspect of plugin parameter management which ought to be integrated into the parameter-handling code. In JUCE, state management is supported through the getStateInformation() and setStateInformation() methods of the AudioProcessor class.
JUCE 5 provides two distinct sets of classes to support parameter automation via an older and a newer approach. The older approach, which pre-dates JUCE version 5, involves instantiating parameter objects based on classes derived from AudioParameter. The newer approach, based around an extensive new class called AudioProcessorValueTreeState, promises more streamlined code and integrated support for undo/redo operations. Neither approach is particularly well-documented, so I decided to investigate both myself.
The older approach, which pre-dates JUCE version 5, involves instantiating parameter objects based on classes derived from AudioParameter:
Updates from the plugin to the host are sent by calling AudioParameter methods, of which there are three:
This three-stage approach is obviously designed for use with continuous controls such as knobs or sliders, but is actually required for all kinds of parameters. (If you omit the …ChangeGesture() calls, the host DAW will not receive the changes.)
Updates from the host to the plugin are received as asynchronous calls (callbacks) to the AudioProcessor::setParameter() method, for which the plugin author must provide an override. In JUCE 5, this method has been marked as deprecated, meaning that it will eventually be unavailable, in some future release of the JUCE library. (And at that point, I would expect AudioParameter and its subclasses would disappear also.) Hence this is clearly no longer the recommended approach for parameter automation in JUCE.
I have put together a practical demo of how to apply this approach in a new project on GitHub at https://github.com/getdunne/juce-AudioParameterTest. For more details see AudioParameterTest.
JUCE version 5 introduces a new class AudioProcessorValueTreeState, intended for managing both state-saving and automation. Parameter values are represented by new classes defined within AudioProcessorValueTreeState, which are probably intended to replace AudioParameter and its subclasses. These are organized into a ValueTree structure, which supports the option of organizing parameters into some kind of hierarchy, and also the concept of automatic undo and redo actions. There are also new “attachment” classes—again defined within AudioProcessorValueTreeState itself—to connect parameter objects to GUI controls with minimal coding.
This will be the subject of my second exploratory project. See AudioParameterTest2.
More to come…