I’ve got a standalone application which I’m considering porting to ARA.
Every time I look into ARA, it looks like a bit of a train wreck to implement.
Does anyone have a sense of what % of users actually have and use ARA support?
I’ve got a standalone application which I’m considering porting to ARA.
Every time I look into ARA, it looks like a bit of a train wreck to implement.
Does anyone have a sense of what % of users actually have and use ARA support?
ARA sounds interesting, and seems like it can provide some benefits in DAWs that support it, but my biggest hesitation is introducing behavior that will vary between DAWs.
the irony
Wha???
I was joking about how a “standard” is causing hesitation because it works differently on different DAWs.
the trick is to not just implement ARA but also a manual capture feature so that everyone without ARA-DAWs can also use the plugin
Ah does it? I don’t know much about ARA which is why I’m asking. The concept is good but the API seems convoluted for even simple things.
I had a manual capture “learn” style implementation, but playing back the same track twice in a DAW isn’t guaranteed to be exactly identical each time, so it seemed to create annoying problems making it a bit clunky.
Integration can be significantly different, but the specifications are clear and well-defined. How to load an ARA plugin varies from DAW to DAW, but the overall functioning of the plugin remains the same. There are particularities for each DAW, but in the same way that each DAW integrates the VST format in its own way…
can you elaborate on the kinds of variations you experienced?
For example if you have a reverb on the track and you seek to a different position (or loop). The reverb will have started at a different time, so the actual audio is different. There are also plug-ins which use random number generators (analog simulators, etc) so their exact behavior can be a little different each time.
It’s usually a pretty subtle difference, but it’s not exact so it can screw things up.
For many cases, it might not matter but for my situation it does.
I’ve been getting some encouragement to go ahead with adding ARA-2 support.
Even if it’s not exactly ubiquitous right now, I’d imagine it will pay off long-term.
I’d be very interested to hear how you get on. Been keeping an eye on it as well.
yeah ARA doesn’t like the inputs to be random. but users know that already and can work with it. once you have captured something into melodyne you have to work with it like that. without ARA it involves a lot of bouncing. i don’t know what kinda design you are planning, but I think people definitely have some tolerance for that limitation
Btw, does JUCE currently support ARA for AAX (Pro Tools)?
Protools doesn’t support ARA plugins yet except Melodyne. Hopefully, the support will be extended to all the ARA plugins soon.
I’ve been finding ARA surprisingly easy to implement. It took one day to get the optimizer to where it can fully analyze and optimize the audio source. It sort of just slotted right into the existing audio file code thanks to JUCE abstractions.
Still plenty more to do but the scale of work is clearly less than I had anticipated.
Is there some standard way to mark your plug-in as ARA-only? It looks like currently, any VST-3 host will happily create a plug-in instances. Is the idea that you’re supposed to just present a message to the user when ARA support isn’t found?
Another question: Do any hosts actually support Audio Unit ARA? Is there something special you need to do to enable AU support? Doesn’t seem to “just work” like VST-3 did.
I only know of Logic when run on Intel Macs or under Rosetta on ARM Macs. I think Apple is working with Celemony on ARA support for plugins run natively out of process in Logic on ARM Macs though, at least that’s my assumption when looking at that ARA IPC code added to the ARA repository lately.
Is the idea that you’re supposed to just present a message to the user when ARA support isn’t found?
Yes. No way to mark a plugin as ARA only.