I’m just starting with ARA plugins, I watched the ADC talks, read the ARA docs, had a look at the JUCE example plugin etc. which already gave me a good overview. But there is one big question for me and that is (how) are host automatable parameters handled in an ARA plugin.
I started testing a bit in Reaper, where I created a track, put two audio files as regions on that track and added a simple ARA plugin to the track that exposes some parameters. I can see that Reaper creates three instances of the plugin, one with the EditorView and EditorRenderer role and the other two with the PlaybackRenderer role, one for each region on the track. When I add some automation to the track, I see that the plugin instance used as EditorView/EditorRenderer receives the parameter updates but not the PlaybackRenderer instances used to render audio at the current playhead.
When adding another track and do the same, I see a second EditorView/EditorRenderer instance for that second track coming up which will receive the parameter changes for automation created on that second track.
Now this is only Reaper specific, I have yet to find out how other hosts handle that which might probably only create a single central view etc. So this leads me to a more general question: How is track based (or Region Sequence based in ARA language) automation supposed to work in ARA? Is this even intended to work at all? I can’t see any API that gives me the impression that it’s an ARA feature to bin a certain plugin instance that might receive parameter changes to a specific Region Sequence. For proper playback rendering, I’d need to query the parameter values for a certain playhead position which is also not really possible to my current knowledge. I come to the conclusion, that it might make sense to not even add automatable parameters at all and rather implement automation features entirely in the plugin instead of relying on the host automation features…?
Would love to get some insight from people that have already built real world ARA plugins!
I don’t have experience implementing ARA myself, but Melodyne has a few automatable parameters. For example a global formantshift parameter. Idk how it works with this offline-processing system but there seems to be a way
Since automatable parameters are always instance specific and the hosts ara implementations are so different, it will be painful I think.
Just thinking out loud, but my only idea right now is to search all other plugin instances, filter them by the track the current instance is on, and then check if a parameter is currently being automated in one of these instances.
This could result in two different automations from two different instances on the same track when the user automates them both, so this would not be ideal I guess.
ARA doesn’t have parameters.
Maybe it’s a useful feature request to simplify it so it’ll be part of the SDK.
Anyway,
ARA persistency is currently exclusive to audio modifications. Those are equivalent to the audio files. Meaning, if you copy a vocal from chorus a to chorus b, they’ll have same processing.
Since ARA gives you access to the entire timeline relevant to the content within the ARA context, you can easily make in your UI editor the relevant parameters.
After some more testing, I get the impression that there are two kinds of ARA hosts out there that present the plugin in a different way to the user.
The one group is represented by e.g. Cubase and Studio One. There you load the ARA plugin for a certain region, the workflow is selecting the region, adding the ARA plugin and then when the user selects the region, the View of the ARA plugin is displayed as an embedded component of the host UI. You can easially add two different ARA plugins to two regions on the same track in those DAWs. This communicates to the user, that the ARA effect is bound to the region and there is no traditional parameter interface exposed to the user for these plugins.
The other group is represented by e.g. Logic and Reaper. There you load the ARA plugin in the mixer just like a normal plugin and if it happens to be the first plugin in the chain, it is instantiated as ARA plugin. Every region added to the track will be rendered by a technically new PlaybackRenderer instance of the same ARA plugin. The plugin still exposes a generic parameter interface and automation can be written. This communicates to the user, that the ARA effect is bound to the track.
I come to the conclusion, that I could avoid confusion here by not exposing any classic host automatable parameters in the first place. But still, there will be parameters affecting the playback rendering.
In my use-case the ARA plugin is not something like Melodyne where you interact with items on the timeline but more like a traditional effect, e.g. just think it would be a compressor which makes some fancy usage of lookahead capabilities that ARA gives you. When an effect like that is loaded in Reaper, the user would probably expect a threshold parameter on the UI to affect the entire track, not just a single region and might also be confused of a UI that exposes the threshold setting per region and not per track. It could even become a quite annoying UX experience if one had to set the threshold for each region on that track if a consistent compression over the entire track should be applied. So I’d tend to try to introduce some magic here that synchronizes the playback rendering affecting parameters for all region sequences, maybe even move the instances of these parameter values to a custom Region Sequence class?
Could you elaborate on this a bit? From my still very sketchy understanding of ARA, I get the impression that I could in theory store the state of all my custom region sequence instances which might hold a region sequence wide state in the DocumentController::doStoreObjectsToStream function? Not sure if there would be any ambiguities when re-applying the state back to the region sequence instances given that there is no such thing as a unique/persistent ID for a reqion sequence?
In Reaper, you can also load plug-ins (ARA and non-ARA) directly onto regions (Take). Furthermore, an ARA plug-in will always be automatically placed at the start of the processing chain (unless another ARA plug-in is already present, in which case this is not supported by the ARA specifications).
It seems to me that it’s possible to retrieve the plug-in’s classic parameters, but this may be a little more complicated depending on the roles - playback renderer, editor renderer, editor view - of the plug-in instance (I don’t use the plug-in’s classic parameters in my ARA plug-ins so I never tried). It’s possible that the information won’t be transmitted to the instance you want. But it seems to me that this can be handled in the same way as passing information from the playhead to the various instances. This has been discussed in other threads.
I think I get an impression of how I could achieve some communication between instances with different roles etc via the document controller. Still I’m not even sure at the moment where to host my parameter instances.
Let’s put the idea to sync parameters for a RegionSequence for aside for now. I had the impression that the AudioModification is the place where parameter instances would be kept. If the JUCE ARA demo plugin is taken as an example, the dimmed setting could be considered some kind of parameter I guess. The demo’s code implements the dimmed parameter management in an AudioModification subclass.
Now I created the following test case:
Create two tracks in reaper, load the ARA demo plugin on each of them
Drop an audio file to one of the tracks. It will appear as region in the plugin
Double click the region in the plugin, so that it’s dimmed
Copy the region in reaper to the other track. The copied region will appear in the plugin as well and is also dimmed
Double click the copied region in the plugin. It switches back to the non-dimmed state. But the other region also switches back to the non-dimmed state.
So what I can observe here, is that both regions share the same AudioSource (obviously) and also the same AudioModification – which somewhat aligns to what is described in the ARA documentation. But what if I wanted to be able to set the region on one track to a dimmed state and the one on the other to a non dimmed state? Would there be any option to dim this two regions individually which would also allow me to store and restore their respective dimmed state? As far as I get it, I could move that dimmed parameter to a custom PlaybackRegion implementation, but since a PlaybackRegion has no persistent ID, there would be no safe way to store and restore their state that way. A completely different approach would be to store that state in the actual plugin processor instance that is used as playback renderer. My testings in multiple hosts revealed that all of them seem to instantiate a new processor instance for a new region and use that as playback renderer for that reason. But that behavior is not really documented anywhere if I didn’t overlook something, so I would somewhat rely on a host implementation detail. Furthermore, to my knowledge there is no callback that notifies a processor instance that it has been created for a specific ARA PlaybackRegion, so it’s difficult to map the control for that to some UI part that works with a PlaybackRegion.
I really get the impression as if I’m either trying to abuse ARA for use cases that it was just not designed for or that I’m overlooking something obvious?
In Reaper, there is an option “Pool ARA edits for all copies of the same source media by default” in Preferences → Plug-ins → ARA. You can either disable this option. Or you can click on the double-square button to the left of the region name.
Thank you again. It would be great if the plugin itself could define that behavior, e.g. if I could instruct the host to always copy the modifications since it does not make sense for the particular plugin instead of globally disabling that for all ARA plugins in the host. I fear that this is not possible? And I’ve yet to find a similar setting e.g. in Cubase…
