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.,

• Plugin to host: user manipulates GUI controls, changes are recorded by a host DAW.
• Host to plugin: DAW recreates user's manipulations automatically using playback.

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. Unfortunately, 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:

• AudioParameterFloat represents a floating-point value, e.g. a value set by a knob or slider. This is the most basic kind of parameter, because floating-point parameters are supported by all plugin hosts, regardless of the specific interface technology.
• AudioParameterInt represents an integer value, e.g. something like a MIDI note-number or velocity.
• AudioParameterChoice represents a discrete choice among a defined set of values, e.g. an oscillator waveform type chosen from the set { *sine, triangle, square, sawtooth* }. You could think of this as a specialized form of integer parameter, where the range is restricted to [0, *number_of_choices*-1].
• AudioParameterBool represents a logical value (*true* or *false*), e.g. whether a certain effect or function is enabled or not. You could think of this a limited form of choice parameter where the available choices is { *false, true* }.

To communicate