Installation of AudioUnits since High Sierra

[MeldaProduction]

Hey folks, so classic thing, but I still got no answer. Since High Sierra (I think), if you install an audiounit, it isn't recognized / changed in Logic (and other AU hosts) until login / restart. So I tried this:

I took MyPlugin.component version 1.2 and placed it to /Audio/Library/Plug-ins/Components. Opened Logic, ok, auval, ok. So now I executed my "installer" for version 1.3, which basically does this:
rm -r /Audio/Library/Plug-ins/Components/MyPlugin.component
cp -a thenewcomponent/MyPlugin.component /Audio/Library/Plug-ins/Components/MyPlugin.component
RESULT: Logic and auval still think its 1.2! Btw. I checked that the new component 1.3 IS there.

So according to this:
https://developer.apple.com/library/arc ... ntals.html
it should be solved by doing
touch /Audio/Library/Plug-ins/Components
For completeness sake I also did
touch /Audio/Library/Plug-ins/Components/MyPlugin.component
RESULT: No change, Logic and auval still report 1.2.

So I thought let's clear the cache, hard way, like every cache I could, so:
rm -r ~/Library/Caches/*
RESULT: Logic and auval report a version mismatch . They apparently realized that the component has changed, but only partly.

So perhaps the component is messed up indeed, right? I restarted the computer.
RESULT: All fine. Nope, the component is and was fine, it's just that restart was needed...

I mean wtf . Apple is killing me... Any ideas how that could be solved so that people don't need to restart after every installation/update?

[george]

Try deleting ~Music/Audio Music Apps/Databases/Tags/
Logic changed their cache location btw. It's ~/Library/Caches/AudioUnitCache folder now and removing that should be enough.
I do admit they are doing some crazy stuff lately and things are getting absurdly complicated.

[BlueprintInc]

Don't know if it helps, but we had this problem with an old AU version. Since we reworked our AU-adapters to AUv3 there were no such caching errors anymore.

We experimented too back then with createing a "standard" installer via packages. This seemed to solve it for at least half the installs. As if it does any extra step to invalidate all caches.

[MeldaProduction]

discoDSP: Thanks, I'll try the "~Music/Audio Music Apps/Databases/Tags/", I was already removing the AudioUnitCache, that led to the version mismatch .
BluepringInc: Hmmm, what is AUv3? Do you have some info? I'm quite afraid to upgrade to anything on OSX , but who knows, if it would help the neverending issues with AU...

[george]

Rebooting sometimes seems to work but for me trashing AU cache and Tags folders seems to do the trick.

[hibrasil]

killall -9 AudioComponentRegistrar

seems to do the trick for me.

Collating relevant notes here:

https://gist.github.com/olilarkin/8f378 ... f47061d70f

[MeldaProduction]

Thanks folks! The "killall -9 AudioComponentRegistrar" actually seems to do the trick!

[Markus Krause]

I am not sure if it is a good idea to add something like a killall command or a deleting of another software's cache to the installer. It's a dirty hack and might open a can of worms if something goes wrong. What do you think?

[MeldaProduction]

Well, it works, steinberg recommends that, and it's caused by Apple's stupidity . So, fine by me

[george]

Rebooting should cause the same effect, right?

[MeldaProduction]

Exactly!

[george]

haven't tested if sudo killall -9 AudioComponentRegistrar can be used on the post installation script but definitely much better than a reboot!

[MeldaProduction]

I tried and seems working!

[Markus Krause]

Thanks for the info. If Steinberg recommends it than we should be safe to use this

[george]

Basically we had to run something like this (17 should be High Sierra, 18 Mojave) on the installers, right?

Code: Select all

#!/bin/bash
if [[ ${OSTYPE:6} -ge 17 ]]; then
	sudo killall -9 AudioComponentRegistrar
fi