Hmm now I’m seeing the issue again even with the system-wide library location and I needed to restart to make a new plugin show up at all. So whatever was fixed in 10.13.5 has not totally solved this problem.
I’m experiencing this issue pretty consistently too now on the latest High Sierra (10.13.6). Is this supposed to have been fixed as of now?
Is this with your development plug-in?
It seems to be working well now for global plug-ins (installed to
/Library) but still broken for user library (
My dev plugins get installed to /Library as well. I’ll have to run a few more tests but it seems like everytime I bump the version in the Projucer the new builds require a restart.
I found that removing the following folder caused Logic Pro X to perform a rescan of plug-ins when it starts:
I’m on macOS High Sierra 10.13.6 with Logic Pro X 10.4.1
I don’t know if this helps in making Logic see newly installed plug-in, but this was certainly beneficial in making Logic understand a change of name in the plug-in:
A previous build of my plug-in was named “OldName” and was seen as such by Logic.
Then I renamed the plug-in project to “NewName” leaving the IDs (aufx ABCD MyPl) and filename intact and still Logic listed it as “OldName”, a sign that it had cached “OldName” in association with those IDs
I switched to “Guest User” on my machine and started Logic there. Under that user, it showed the correct name “NewName” for the plug-in, so that got me convinced that the cache was stored on a per-user basis.
I switched back to my regular user account and started looking around in
~/Library/Caches/ which sounded promising, and pronto I found that
I deleted it and, when I restarted Logic, I got the small notification that it did a rescan of the AUs. After that, the plug-in was correctly listed ad “NewName”.
I’ve just ran into this issue again with a customer and keep getting it everytime I start a new plugin project. Has anyone found a solution in the meantime? Or do you now just require a restart after installation? I appears to happen on Mojave as well, but has it maybe finally been fixed on Catalina?
killall -9 AudioComponentRegistrar
Thanks heaps! Do you do this as part of the installer scripts?
… later that day …
Thanks even more! Confirmed working with a post-install script on my AU installer package. Finally a working solution.
On what Mac OS’s is this available? Is it available on everything from High Sierra on?
It only depends on “killall” which was probably available on OS X 1.0. If there is no process called “AudioComponentRegistrar”, it’s just going to do nothing.
Thanks, good to know.
Just be aware if there is no process called AudioComponentRegistrar killall will return an error code. If killall is the last command in your script then your script will return that error code and your package install will fail. So you should end you script with
Anybody has insight, on which OSX versions AudioComponentRegistrar exists?
Google and the apple site are quite silent when being asked for that keyword.
Great to finally have something to go on, thanks from me as well @olilarkin!
- @olilarkin already did a clean workflow for your installers
- I did brute force for all of us just as it’s interesting.
10.12 or below has no AudioComponentRegistrar process.
might be nice to add this also to JUCE copy AU stage.
Is there something more to do in addition to:
killall -9 AudioComponentRegistrar
I’ve just witnessed a case in which the AU was failing the auval with “didn’t find the component” error.
Issuing the command above didn’t solve the problem, but rebooting did, and now the exactly same AU is successfully validated
this is macOS 10.15.6 and the AU was built with Xcode 11.6
I think the iterm2 problem with auval could still be around somewhere…
What happens is due to some environment settings, auval only validates apple plugins, but no 3rd party. In that case it says “-50 - no component found” and doesn’t list them using
But that wouldn’t change after a reboot… strange
And also, I was not using iterm2, I’m still using the default Terminal that comes with macOS, and in fact with
auval -a I could see other plug-ins that I built, not just the Apple ones
I add a postinstall shell script to my pkg that runs:
killall -9 AudioComponentRegistrar; auval -v Your Plug Code
Update: apparently Apple Silicon AUs don’t require the restart, but Intel ones (or running via Rosetta) still do (tested on macOS 11.1 on M1 MBP 2020)
I have never had to restart, as long as I just move the plugin out of the
Components folder, wait 10 seconds, then move it back. Just throwing it out there.