Preview Rendering in JUCE_ARA Plugin

Hi Everyone,

I’m working on a Melodyne-esque ARA plugin and am having trouble implementing the preview rendering functionality. Currently, I’ve created an implementation of the juce::ARAEditorRenderer class and am feeding white noise into the processBlock function (the editor renderer is created by the document controller by overriding the doCreateEditorRenderer function).

From what I understand, the editor renderer instance is responsible for all preview renders and should only play audio when playback is not happening. In my case, however, the white noise generated in the editor renderer is heard in addition to the playback audio from the audio source ONLY when playback is occurring.

What do I need to do to properly implement preview rendering in the ARA framework? Any advice or examples that show this are greatly appreciated. Thank you very much.

1 Like

On what plug-in format are you testing it? AU, VST3?

I’m currently testing AU format in Logic Pro, thank you

Then test your plug-in as VST3 (you can get REAPER up and running quickly for evaluation).

Logic Pro is very pedantic about processBlock

I’ve actually tested a while ago and indeed it has a specific code-path for Melodyne identifier(s) to keep calling processBlock while idle/no audio.


Interesting… thank you for the tip, I’ll try vst3 & reaper. That being said, does that mean there is no way to implement preview render that works in Logic Pro unless Apple hardcodes it?

That’s should be discussed with Apple /Logic team since many ARA plug-ins might need this.

1 Like

Curious: is this with the Celemony-modifed version of one of the JUCE SDKs, or has ARA been integrated into JUCE now? If it’s in JUCE now, what version is needed for that support?

Here check this out and see for yourself!

Yes, I have pulled that code, but I was hoping that they’d added the ARA stuff directly into the latest JUCE SDK. When they do, it will make things a lot easier to keep up to date.

Just my 2¢: ARA would be better off as a nice and tightly scoped JUCE module, probably under Celemony’s umbrella.

Not only is the ARA code pretty out there in terms of design, being unintuitive and not fitting anything JUCE has, from what I can tell its fork doesn’t even need to be a fork. That and the module approach means its functionality will only need to be pulled in as needed, and will be properly decoupled from JUCE itself.

1 Like

@jrlanglois Being involved in creating that code, I fully agree that ARA feels pretty alien in JUCE the way it’s done in JUCE_ARA, and would like it see decoupled further. However, given that it needs to tie into the plug-in wrappers, Projucer, etc, and that it’s using the model graph and associated code that is defined in the ARA SDK, I’m very curious how to improve this situation - any suggestions are highly welcome!


I’d love to! Aside from the usual problem of time, the main issues are that I don’t know what the requirements are for embedding ARA directly, nor why that must be the case. That and there are many changes in your fork where lots of them are uncommented, or commented with a TODO.

For example, the commit stating Enforcing that processing latency is 0 if ARA is enabled. doesn’t properly explain why that’s the case, nor how that makes sense if someone does add latency.

If your code or commits (or really… both!) would explain the ‘why’ behind the changes it would go a long way.

Being aware of the JUCE_ARA fork and having discussed it with people at Celemony and SoundRadix we are actively working on closely integrating the ARA SDK into JUCE.

We are hoping for a solution that will fit into the usual JUCE development workflow, and adds ARA capability to hosts and plugins by enabling the ARA format in the Projucer or CMake. The JUCE_ARA fork goes a long way to that on the plugin side already.

ARA enabled plugins however can have a large number of interactions with the host and have to behave correctly in a lot of possible states, and I don’t think even a closer integration can make that go away. So it will still be necessary to have a good mental model of how ARA hosts and plugins interact with each other. There are a lot of assertions in both the ARA libraries and JUCE_ARA codebase, and many of them are there to help enforce that mental model and general understanding of the ARA concept.

That said a minimally viable ARA plugin doesn’t have to require a lot of added code, although it will only utilize a thin slice of all that the API allows. Hopefully tutorials and comments can make writing ARA plugins gradually approachable.


JUCE_ARA is an experimental branch, intended to explore how to create a potential integration. The TODOs indicate areas of work before this can become stable JUCE API.
Its “develop” branch is not intended to be merged back - there’s a “condensed” branch instead that gives a better overview of how the integration would impact JUCE; it might be used for a merge, or the JUCE team might just pick whatever parts of the code are useful and discard the rest of the fork.

Working with ARA requires understanding its basic concepts properly - ARA is very complex, but comes with fairly extensive documentation. At minimum the chapters “ARA Design Overview” and “Implementing ARA” should be studied. (The latter includes the explanation why ARA playback renderers must be latency-free from the host’s perspective.) Repeating these docs in code or commits does not seem appropriate.

I understand what TODO means. The reason for my bringing it up is to point out that we don’t know any of the intentions - answering ‘why’ something is still left as TODO as well as outlining why a changed is made are the biggest steps forward into getting any community involvement. Otherwise we’re left guessing as to what the plans are for the code on your end. So far, your commits state the ‘what’; answering ‘why’ helps anybody else looking at your work, giving a sense of an outline even if there isn’t an explicit plan.

I’m on the fence about that statement. To some extent I agree. But keeping in mind that the community hasn’t been around the technology much, redundancy can definitely help.

How it all works together makes sense to be left for your extensive documentation.