ARA and Playhead

Audio Plugins
1

ARA offers the possibility to control the audio playback, the start position, the loop, etc. To take full advantage of this capability via the plug-in interface, the plug-in must also be aware of this information from the host. This is possible by retrieving the AudioPlayHead in the processBlock() method. The problem is that with ARA, there can be several processor instances (juce::AudioProcessor & juce::AudioProcessorARAExtension) per plug-in actually loaded by the user. And these instances can have several roles depending on the host implementation and the context - ARAPlaybackRenderer, ARAEditorRenderer or even ARAEditorView (for the graphical part).

If we want to display and control the AudioPlayHead information, from which role should we get this information? I would say from the ARAPlaybackRenderer. But I have a problem especially in Reaper (I have to do more tests with other host software):

In Reaper, when an ARA plug-in is loaded on a region (and not on a track), Reaper creates several instances of the processor (juce::AudioProcessor & juce::AudioProcessorARAExtension), one which is ARAPlaybackRenderer + ARAEditorView and the other just ARAEditorRenderer. Once the audio playback starts, the method getPlayHead()->getPosition()->getIsPlaying() returns true in processBlock() (which is obviously) in both instances of the processor. On the other hand, if we stop the audio playback, the processBlock() method of the ARAPlaybackRenderer + ARAEditorView instance is not called anymore, so for this instance the audio playback state is still active and the playhead position does not move, etc. As this is the instance used to retrieve the information (and also in charge of the GUI), the UI cannot be updated properly.

Should we use the AudioPlayHead information from the ARAEditorRenderer instance instead? This complicates the communication with the GUI. And is it compatible with all hosts?

I also note that it is better not to use the AudioPlayHead information from all instances at the same time because due to the multithreaded approach, the information is not synchronized.

I hope the explanation is not too messy :sweat_smile:

2

Not sure if it’s the right way to do things or not (ARA is not easy!), but, when bound to ARA, when we check for the transport stopping, we check if our processor instance is an EditorRenderer. If not, then we search through a list of processor instances we maintain, and find the Editor Renderer instance for the current instance’s Document Controller, and get the playhead info from that.

1 Like
3

Yes, it’s a bit complicated, it would have been nice to have a simple approach to rely on. But thanks for the tip, I’ll be looking in that direction!

4

Oh, we also have a check in a timer callback to see if processBlock has not been called for 1 second when we think. the transport is still running, and we stop all activity related to the transport in that case. I forgot about that bit for Logic.

1 Like
5

Thanks! I think I understand your approach, it seems it could fix my issue! I have also contacted the ARA development team. It might be interesting to get their insights.