Hi folks,
I’m trying to use ARA in one of my project, and I’m currently facing a very akward issue : Even if the ARAFactory is correctly created, the DocumentController is never bound. I tried to trace back the cause the best I can but it ended up in some native MacOS/AudioUnit code which is not open-source. I managed to figure however that the property kAudioUnitProperty_ARAPlugInExtensionBindingWithRoles is not set. I’ve searched how to enable such flags but without success. I thought it was related to the .plist or the .jucer but found nothing there. Am I missing something?
I’m building and testing under MacOS 12.3.1, runing on M1 chipset. I’m aware that the new separated-thread hosting of Logic is incompatible with ARA, hence I’m testing under Rosetta2. I tried Logic 10.7.2 & Reaper 6.63, so they should both be compatible with ARA. The VST3 version works fine in Reaper. JUCE 7.0.1 & ARA 2.1.
I can reproduce the bug in the ARAPluginDemo as well, and got the error ARA host isn't detected. This plugin only supports ARA mode, because as the DocumentController is not bound, the DocumentView is never created.
Have you encountered such issues? Any clues? Am I doing wrong with the exemple project?
Thanks in advance,
ZeCroque
I can repro the issue and will get back to you once I’ve understood the problem.
To make sure:
I can reproduce the bug in the
ARAPluginDemoas well, and got the errorARA host isn't detected. This plugin only supports ARA mode, because as the DocumentController is not bound, theDocumentViewis never created.
On Logic Pro X with Rosetta - does the ARA AU works as expected?
As of writing this. AU-ARA2 variant isn’t supported on any other host except Logic Pro X at least from my knowledge. So all other hosts should use the VST3 variant.
Nope, it doesn’t work in Logic with Rosetta either! 
I’ve tested REAPER and it doesn’t seem to support ARA with AU plugins, so as ttg mentioned, VST3 is the way to go. Unfortunately I’ve temporarily lost the ability to run Logic under Rosetta after upgrading it.
However, when running the plugin under Rosetta, you need to make sure that the plugin binary contains an x86_64 build. By default a Debug build on an M1 will only contain an arm64 build and you won’t be able to open it in a DAW running under Rosetta.
To enable x86_64 in Debug builds too, you can add the following argument to CMake
-DCMAKE_OSX_ARCHITECTURES="arm64;x86_64"
Or you have to disable the “Build Active Architecture Only” option in XCode’s project explorer for your target.
You can verify what architectures your plugin contains by running
lipo -archs MyPlugin.component/Contents/MacOS/MyPlugin
OK, I have Logic running again, I’m still seeing the problem, so I’ll keep looking.
Ok thanks ! 
BTW, I think it’s not that relevant now you’re reproducing the bug as well but I can confirm that the lipo command line you sent me returns that my binary is indeed x86_64.
Did you successfully load any ARA plugin into Logic, like Melodyne? Only suggesting this sanity test because we’re facing no such problems with our internal builds…
Yes, the issue is caused by a missing ARA tag in the plist file, and only affects the CMake build. A fix is on the way.
The fix is out on develop
Nice! I’m not sure about the issue being CMake-only however! My main project is using the Projucer and I’m pretty sure it encounters the same issue than the demo project that I built with CMake. I’ll double check and get back to you.
Yup, I was correct, I’ve got the same problem with the Projucer on my project!
I’ll test your fix on the CMake template tomorrow. Good evening (if it means something in your timezone)!
I tested this yesterday with the File → New Project → Open Example → Plugins → ARAPluginDemo and it worked correctly. That uses the ARA Plugin project type.
Now I also created a plain plugin project and enabled the ARA checkbox in its preferences and this works too. In both cases the only gotcha was adding the x86_64 architecture. I don’t have any ideas right now.
Okay, I’ve tested a bit more and I figured that I wasn’t testing correctly in Logic. Thanks to @yairadix for suggesting its sanity check! I was instanciating the plugins on the master bus, so I was doomed anyway… I’m mainly a Windows user so I don’t know Logic very well and the differences between the behavior of ARA VST3 and its AU counterpart are very confusing (ARA is working on master with VST3). Funny enough I provided feedback for a bug I was not reproducing ATM 
I tested afterward, and I can confirm it indeed works with the Projucer and that your fix is working as expected.
Now the bad news: Although I can finally instanciate my plugin, the waveform is not shown inside the exemple plugin, and I’m crashing whenever the DAW’s playback starts… I traced by the crash and it is an except fired in PlaybackRegion::updateProperties :
ARA_VALIDATE_API_ARGUMENT (properties, (properties->transformationFlags & ~supportedTransformationFlags) == 0);
Can you reproduce it?
Thank you very much for your help!
Specifically Logic’s ARA implementation isn’t the very best. Try pressing “play” in Logic and seeing if the waveforms do appear after.
I encountered a similar crash l.604 of ARAPlug.cpp (note that this is in debug mode only because ARA_VALIDATE_API_CALLS is defined only in debug except if you force it in release) because there seems to be a very small difference between the durationInModificationTime and durationInPlaybackTime. The problem seems related to Logic only which is not supporting ARA very well. Anyway, I’ll try to create a reproducible test to figure out what happens exactly.
Yep, I’ve reported this one to Celemony and I’ve locally removed the assertion. The good news is that the other assertions work fine for me in my internal dev.
Note that you don’t have to crash upon an assertion in debug builds - just define ARA_HANDLE_ASSERT to something more appropriate when compiling ARA_Library.
Maybe we should generally insert jassertfalse here?
I’m hesitant to remove any ARA assertion because they are an important tool to find bugs, and many ARA devs rely on them.
Thank you for bringing this up, we have pushed a fix for this issue, which is now also part of the 7.0.2 release.
The ARA assertion is now correctly redirected to a JUCE assert function that isn’t calling abort().