Maybe I misunderstood the goal, because, if I understood correctly, this one line does it for me in a Reaper script:
reaper.Main_OnCommandEx(41051, 0, 0)
You could also do it in Ardour… by recompiling it…
Maybe I misunderstood the goal, because, if I understood correctly, this one line does it for me in a Reaper script:
reaper.Main_OnCommandEx(41051, 0, 0)
You could also do it in Ardour… by recompiling it…
Right, you can call the built-in Reaper action for that exact operation, but you can’t as easily do other audio processings. (Reverse and normalize are not really interesting things to actually implement with ARA, but they are the easiest examples to mention to describe what ARA allows to do compared to “normal” plugins.)
Point taken.
For my current purposes, Reaper blows anything else out of the water, as it can both notify a plugin of added tempo and meter changes, and create them on command from a plugin. For a replacement piano roll, that pretty much covers the requirements. ARA doesn’t appear to allow creating them on command, only telling the plugin about them. I haven’t yet done much audio pluginning with Reaper.
BTW, I’ve registered with Celemony and downloaded the SDK, and also asked a few questions about GPL.
So far, it seems all of the legal aspects have not yet been finalized, but the github fork of JUCE should have “the same legal implications” as the original. Still, I’m not 100% sure if forking something on github that is available with a dual GPL/commercial license explicitly means that the fork carries the same option. It would seem to, I guess. At any rate, they have not told me that it doesn’t…
The ARA SDK may not be modified or redistributed, but AFAIK this was also true of VST2 SDK, and there were plenty of open source projects that required that.
RE functionality, he also said that MIDI is one of the main requests they get, but so far it’s not there, just audio and, importantly, some program access (e.g. the plugin knowing where tempo and meter changes are in the host).
Thanks for sharing @Chuckk, very interesting!
ARA iscan be very useful for audio analysis plugins where the constraints of having to work in a causal real-time way don’t make sense. I’m thinking (non-real-time) audio transcription plugins, for example.
I still haven’t read the details (ARA has been around for some time now), but I assume it would allow a plugin to transcribe audio in an audio event or track in one go into a MIDI part (without having to playback the audio).
Does anyone know of a list of hosts that already support ARA?
Some minor details worth mentioning (also related to your (@KoenT) question).
Hosts supporting ARA:
While focused on Melodyne, this page provides details about ARA compatibility with hosts.
https://www.celemony.com/en/melodyne/editions-and-technical-matters
Just that it does not yet have any MIDI capabilities. You can, of course, use the regular MIDI capabilities of VST and AU, but they will only respond to real-time messages, AFAIK.
OK, I see…
As long as MIDI track access is not supported, a transcription plugin could still use ARA to process all audio in one go, and then build up a MIDI sequence in the plugin internally which then becomes available for the user to drag and drop into a MIDI track in the host (manually of course). It’s still not ideal, but it helps.
Anyone who has had a look at the ARA SDK know if it also provides random access to automation parameters? I.e. Not just the current value of a given automation parameter, but also the value anywhere along the timeline?
As far as I know, there isn’t such a facility in ARA.
ARA plugins don’t have automatable-via-host’s-UI parameters like VST, and doesn’t have access to other plugin’s parameters, but they can implement an internal equivalent to automation parameters.
If I remember correctly, an ARA plugin can only be placed as the first plugin in a plugin chain. But in most cases an analysis plugin makes most sense at the end of a plugin chain. That’s why I don’t think ARA is very useful for the common kind of analysis plugins.
Your example of an audio transcription plugin could be placed as the first plugin, though.
Since ARA isn’t open-sourced.
From the questions here I believe the best would be to contact Celemony here:
ara at celemony dot com.
And they’ll be more than happy to provide you with SDK so you could try out ARA2.
REAPER can be used for first evaluation. although ARA still has some pitfalls with each host doing things a little different.
In the meantime even poking at the JUCE ARA would give you some understand of ARA.
Thanks for making this great work available.
Before I get into that, can I ask what the license of the JUCE ARA fork is? What would be the conditions to use it on top of JUCE’s license?
Thanks again
As far as I know, ARA is closed-sourced so terms are subject to the ARA license itself.
@sgretscher from Celemony might be able to provide more details if he’s within the JUCE forum.
But I guess you should simply contact Celemony here:
https://www.celemony.com/en/service1/about-celemony/technologies
If you would like to support ARA Audio Random Access™ as a developer and are interested in the ARA SDK, please contact ara@celemony.com.
Thanks, via the company I work for, I have access to the ARA SDK. My question goes specifically to the modifications of the JUCE fork. Currently we have our plugins implemented each one separately.
I wanted to explore the option of a common code base by introducing JUCE, but the deciders are hesitant because of license concerns…
I guess you should e-mail Celemony but I’m pretty sure the JUCE contributions aimed to keep the JUCE license the same.
Great, thanks! I assumed so too, but since the JUCE fork was presented as a joint-venture, I couldn’t say who is in charge… I will check with Celemony
And especially in legal issues, my assuming is a bad idea
Are there any plans to add ARA support to the official JUCE version? It would be a great addition to JUCE and it seems as if Celemony has already done most of the job.
Best,
Stian
Would it be possible to get an official statement regarding ARA support? We’re using the ARA branch and it seems to work very well so far.