Both sides previous revision
Previous revision
Next revision
|
Previous revision
Last revision
Both sides next revision
|
juce_and_parameter_automation [2017/10/22 20:16] shane [The newer approach: AudioProcessorValueTreeState] |
juce_and_parameter_automation [2017/10/22 20:31] shane [JUCE and parameter automation] |
**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. | **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. | 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: AudioParameter ===== | ===== The older approach: AudioParameter ===== |
| |
Updates //from the plugin to the host// are sent by calling //AudioParameter// methods, of which there are three: | Updates //from the plugin to the host// are sent by calling //AudioParameter// methods, of which there are three: |
* **beginChangeGesture()** alerts the host that parameter changes are forthcoming | * **beginChangeGesture()** alerts the host that a sequence of parameter changes is forthcoming |
* **operator=** (which itself calls //setValueNotifyingHost()//) sends the update | * **operator=** (which itself calls //setValueNotifyingHost()//) sends the update |
* **endChangeGesture()** informs the host that this sequence of changes is done | * **endChangeGesture()** informs the host that this sequence of changes is done |
| |
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. | 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 | 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 |