I have had a lot of bother getting my head round AUv3s both with JUCE and just directly using Apple’s frameworks.
AUv3s appear to something not quite yet turn-key to build with JUCE and information of how they work and the problems you can run into (mostof the time self-inclficted) is thin on the ground.
I originally had this posted in OSX 10.15 debug AUv3 in Logic, but it now seems the wrong place for it. I am making this thread in the hope that other poor souls bashing their head against this for the first time might stumble across the right bit of information.
If you have self-sabotaged your own AUv3 project or resolved a pretty weird error share below.
NB: I’m not particularly interested in AUv3s, but the process of getting them to run on another machine has been so frustrating, I just want to get it to work out of spite.
Project Not Building
Problems relating to reasons an AUv3 project does not build
Embedded binary is not signed with the same certificate as the parent app
“Embedded binary is not signed with the same certificate as the parent app. Verify the embedded binary target’s code sign settings match the parent app’s.”
This error comes about for reasons I don’t fully understand, but that are fundamentally down to code signing.
To avoid this error
- In Signings & Capabilities set both the
.appex
and.app
to Sign to Run Locally - Do not set Development Team ID in your
.jucer
project under your Xcode Exporter settings
To actually sign the .app
and .appex
you will need to either
- notarise via xcode† or
- Via Terminal:
codesign --force -s "Developer ID Application: Your Name (YOURID)" /path/to/App-with-appex.app -v --timestamp
Given apps from Catalina onwards now need to be notarised, it seems silly not to take that approach.
Hardened Runtime is not enabled
As a sub-issue of sorts, if you Archive an app with no signing, then you will get an error during notarisation stating Hardened Runtime is not enabled even when it is. Make sure Signing & Capabilities at least has Sign to Run Loaclly checked.
AUv3 Not Registering
Problems relating to an AUv3 not registering.
Your AUv3 has registered properly if it appears when you run:
auval -a
in Terminalpluginkit -m
in Terminal
Run the Standalone App first
Obvious to everyone except myself, but you need to run the standalone app before the AUv3 is registered by PluginKit or whatever it is that is registering appexes. You don’t need to sign if you are running on your own machine, just make sure it is Sign to Run Locally
Restart your machine
After running the app for the first time, I have had to restart my machine in order for the AUv3 to be registered. This is the case not just for High Sierra, but I found I have had to do it for Mojave as well.
No App Sandbox
A self-inflicted problem trying to guess the cause of another problem. The .appex
need both the App Sandbox and Hardened Runtime Capabilities. If the .appex
only has Hardened Runtime for notarising, the AUv3 will fail to register
AUv3 not Loading / Mounting
Your AUv3 is registered, but is either greyed out in your DAW or shows as red text in AudioPluginHost. Probably channel configuration related
Assertion failure in +[NSServiceViewController currentAppIsViewService], /BuildRoot/Library/Caches/com.apple.xbs/Sources/ViewBridge/ViewBridge-401.1/NSViewService.m:131
some variation on
Assertion failure in +[NSServiceViewController currentAppIsViewService], /BuildRoot/Library/Caches/com.apple.xbs/Sources/ViewBridge/ blah blah
my specific version
Assertion failure in +[NSServiceViewController currentAppIsViewService], /BuildRoot/Library/Caches/com.apple.xbs/Sources/ViewBridge/ViewBridge-401.1/NSViewService.m:131
Short version to fix this: Channel configurations.
Edit: Actually this might be a red herring, this error seems to come and go as it pleases with no real rhyme or reason.
Solution 1: Plugin Channel Configuration
This was sorted for me by stipulating a specific channel configuration in the .jucer
project settings under Plugin Channel Configuration.
This introduced a separate problem in that the boiler plate JUCE project needed to be changed from
MyPluginAudioProcessor::MyPluginAudioProcessor()
#ifndef JucePlugin_PreferredChannelConfigurations
: AudioProcessor (BusesProperties()
#if ! JucePlugin_IsMidiEffect
#if ! JucePlugin_IsSynth
.withInput ("Input", juce::AudioChannelSet::mono(), true)
#endif
.withOutput ("Output", juce::AudioChannelSet::stereo(), true)
#endif
)
#endif
{
}
to
MyPluginAudioProcessor::MyPluginAudioProcessor()
{
}
Solution 2: follow the tutorials
Follow the Tutorial: Configuring the right bus layouts for your plugins to do Channel configuration correctly using isBusesLayoutSupported
Manufacturer and Subtype Codes
This one is probably the most frustrating as I can’t really wrapmy head around what is goin wrong. I have 2 identical projects
Project 1 manufac: Manu
Project 1 subtype: Qbcz
Project 2 manufac: Jhmh
Project 2 subtype: Mvcf
Project 2 refuses to work in any DAW
- Passes
auval
- Works in AudioPluginHost
Both apps are exactly the same. I sign and resign, restart my machine multiple times, no improvement
I change the Project 2 codes to
Project 2 manufac: Zhmh
Project 2 subtype: Zvcf
and all of a sudden it works absolutely fine. If anyone has an answer for this one, I am all ears. The only lead I have is that consistently the first plug-in listed by auval always has the Assertion failure in +[NSServiceViewController currentAppIsViewService]
error from above. That said, Project 1 is listed firsts, now shows this error, but continues to work absolutely fine.
† in the past, Xcode documentation has been atrocious, but the most recent version is actually not that bad all things considered. Keep The Xcode Docs handy