| Both sides previous revision
Previous revision
Next revision
|
Previous revision
|
juce_and_parameter_automation [2017/10/22 20:06]
shane [The newer approach: AudioProcessorValueTreeState] |
juce_and_parameter_automation [2017/10/22 20:32] (current)
shane [The newer approach: AudioProcessorValueTreeState] |
| **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 |
| 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. | 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]]. |
| |
| ===== The newer approach: AudioProcessorValueTreeState ===== | ===== The newer approach: AudioProcessorValueTreeState ===== |
| 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 (it would appear) are 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. | 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. |
| |
| Unfortunately, the only tutorial code Roli, Inc. has provided to date for this new approach is a toy example, which is so small and limited that it provides no guidance for how to apply it in a practical plugin. This will be the subject of my second exploratory project. | This will be the subject of my second exploratory project. See [[AudioParameterTest2]]. |
| |
| More to come... watch this space. | More to come... |
| |
