I would assume they require separate validation. They are going to be built at least with different set of defines that could mean significant differences, e.g. JUCE_IOS and so on.
E.g. open the App Store on your mac, find and install an AUv3, run the Standalone app that comes with it, then run auval -l | grep AUv3
You’ll see the usual line including a path to the appex: file:///Applications/TheAppName.app/..../TheAppName.appex/
It’s possible then to validate this with auval -v TYPE SUBT MANU
Question 2:
I want to validate (and ultimately debug) a local build, not something installed via the App Store. But of course you can’t simply point auval at the path to a locally built appex (thanks Tim Apple!)
Anyone got any good ideas how best do this?
Thanks!
Isn’t auvals’ purpose to validate AUv3? Therefore, run it on the AUV3 build of the plugin. Then validate standalone. See also, tracktions’ pluginval (ymmv).
The main difference is that iOS targets will use iOS platform APIs and types, whereas macOS targets use macOS APIs and types (e.g. UIView vs NSView).
It’s always a good idea to test products on the target platform. An AUv3 product that runs on macOS isn’t guaranteed to be bug-free on iOS - but it will probably be pretty close.
You can add a loop like this somewhere, perhaps inside createPluginFilter():
while (! Process::isRunningUnderDebugger())
Thread::sleep (250);
Now, whenever you try to load this plugin, it will spin until the debugger is attached. If you try to validate the plugin in auval, you can attach to the plugin process (not auval itself!) and debug it that way.
You don’t need to install an app through the app store in order to register bundled AUv3s. Just launching the Standalone target should be enough. After that, running auval -l should list the AUv3, along with its three four-character id codes.
You may need to run auval from the built-in Terminal.app rather than a third-party terminal like iTerm. You may also need to run killall -9 AudioComponentRegistrar before launching the standalone and running auval in order to detect new AUs.
An AUv3 product that runs on macOS isn’t guaranteed to be bug-free on iOS - but it will probably be pretty close.
Thanks for confirming that!
Yeah that’s something I’ve used before but didn’t know about isRunningUnderDebugger, that’s very handy thank you!
Just launching the Standalone target should be enough.
Your reply prompted me to check my assumptions… I just assumed, incorrectly, that I couldn’t launch an iOS build of Standalone on macOS from Xcode… but it’s simply available as a launch target and I did not notice that before. Thanks again for helping me get there.
For anyone else reading this, it doesn’t seem possible to debug arm auval without turning off SIP. Since a couple of versions of auval ago you can’t modify the binary with new entitlements and resign on arm macs because the arch of the binary for is arm64e which doesn’t permit this. Search for arm64e in this:
