Installing new Audio Units requires restart in High Sierra


#1

Since macOS High Sierra, installing Audio Unit plugins seems to always requires a restart (or at least a re-login) before hosts see them.

Even though we noticed it for all plugins we checked, some folks report that “some AUs require restart, some don’t”.

Does anyone know more about this? Is there any special juice required for new AUs to be listed? If so perhaps this juice could be incorporated into JUCE? Is there something new that installers need to do?


Strange - Vanilla AU not passing auval
#2

We at ROLI here would be very interested in this as well. I’ve spent a few hours trying to figure out why but could not find any hints. Even some open-source plug-ins that don’t use JUCE require a restart in High Sierra.

If anybody knows a workaround for this that would be amazing!


#3

Is this all AUs or just v3s? Don’t have a high sierra machine clost to test, but did you try registering with pluginkit?

pluginkit -a blahblah_auv3.appex


#4

This is for AU v2. But according to reports not all of them (though no mention of specific one that works). Perhaps it’s those that have AUv3 which don’t require restart - answer unknown…


#5

I have to restart to find new AU and AUv3s every time :frowning:


#6

For AUv2, the workaround I use is to move the .component out of the installation folder, restart the host, move the plugin back into the folder, restart the host and the plugin shows up. (Sometimes need to do this whole operation twice)


#7

As soon as High Sierra came out we started getting reports of this, in both our JUCE and non-JUCE products. We haven’t come up with a solution more sophisticated than “reboot” though.

It’s not really AUs, but Logic, I think. The AU is instantly recognized in other AU hosts (Live, Studio One, etc.) that don’t use the Validator, best we can tell.


#8

I’ve seen similar issues when building a JUCE plugin. A first (debug) build using High Sierra would not scan in auval (and hence not show up in Logic Pro X) until I log out or restart the mac. Funnily enough, despite the file being visible in Finder and in the terminal, auval claims that the plugin does not exist. After a reboot, auval does ‘see’ the plugin and validates it successfully, after which it shows up in Logic Pro as well.

Using the exact same project and process this happens on one machine but not on another one. Very confusing. The same project compiles perfectly fine on the same two macs when running Sierra. Note that High Sierra did upgrade the file system to AFSP.

I have found one work around for my case when building plugins. If I rename the AU plugin from its original name (let’s say juce_plugin.component) into something else (juce_plugin2.component), and then rename it back to its original file name (juce_plugin.component), auval scanning works fine and the plugin shows up in Logic Pro as well.

Don’t ask me why this works… :-/ The issue seems to be with auval claiming the file is not there until it is renamed, the user logs out, or the mac is rebooted.


#9

Are you saying that a simple mv Plugin.component tmp && mv tmp Plugin.component solves this?


#10

“Solves” is a strong word. Ibuprofen doesn’t “solve” a headache. It just makes it so you can ignore it. :slight_smile:


#11

If it makes all the symptoms disappear and effectively causes the users to be perfectly satisfied, then even if it’s not the most elegant solution, it may effectively be a solution to the problem.


#12

@djb is launching Logic between the two mv calls part of the solution?
If not it sounds like a placebo solution…

I can’t test, I am still on “low sierra” 10.12 (all threads about high sierra don’t make me wanting to upgrade, but doesn’t help, if my users are having the problems instead of me)


#13

The workflow that worked for me on the mac with issues:

  1. Build the project
  2. Run auval in the terminal; plugin could not be validated (even if attempted multiple times)
  3. Rename plugin in Finder, and rename it back
  4. Run auval in the terminal again; validation works all of a sudden.

Just FYI:

  • The problem happens on one specific mac, not on another one.
  • The problem only occurs with High Sierra + AFSP, not with Sierra.
  • The problem is reproducible with many JUCE projects I have (not just one project specifically).

Whether the plugin shows up in Logic or not seems to depend on auval (if auval does not find or validate the plugin, it won’t show up in Logic).

If anyone can reproduce this workflow let us know. Also any light why audio units don’t validate without trickery in High Sierra, while it works fine in Sierra is much appreciated…


Issues Loading Audio Units
#14

Some AUs won’t show, some will. I was able to reproduce this for JUCE/non-JUCE plug-ins and with APFS and without it…

To be honest, I really think Apple should resolve this. wonder if anyone within ROLI got in-touch with them.


#15

Yes, this issue or similar ones have been occurring since AudioUnits were first announced. It’s not especially new, as such. It’s so omnipresent, we actually have years-old internal company shorthand for it. It started with someone saying “I have to turn around three times, spit, and wave a rubber chicken over the AU,” and has since been shortened to “chickened.” As in “the AU is chickened; hold on.” I just checked, and the first mention of “chickened” in our chat logs is in 2009.


#16

I just got a “new” mpb 2015 and ran into this issue as well with High Sierra. While similar stuff has been happening since a long time, this seems to be much more widespread. The problem also happens in AU Lab, which I use for testing.

The workaround above tells us to use a finder rename, but I can confirm a dual “mv” in Terminal works as well. This means the workaround could be automated in an installer. However, it’s not clear yet whether this would even happen after an install. For me it happened when building a plugin for the first time on the new machine and having it placed in the user Library/Audio/Plug-Ins folder.

Then I tried using a .pkg installer that installs to the system wide Library. Unfortunately none of the workarounds worked on that and a restart was the only way to get hosts to see the AU.


#17

Thanks for letting us know!

Time for Apple to solve this mess :-/


#18

Good luck with that…


#19

I doubt Apple will fix this any time soon. What would be nice was a reliable way to make what’s left of the Component Manager perform a rescan of the available components. This could maybe be done in a post-install script, but so far no luck. I guess that is what the renaming sometimes triggers. I already tried running “touch” on the installed files, but it does not help.


#20

Does anybody know of any AUv2s which work without a restart on High Sierra?