AUv3 plug-in not seen by DAW


#1

I’ve built the AUv3 version of the JuceDemoPlugin ( along with the containing app ).
The containing app runs fine.
I’ve purged the ~/Library/Cache/ and deleted ~/Library/Preferences audiounitinfohelper as described elsewhere.
The appex will not show up in GarageBand, Logic Pro X, or any other AUv3 aware DAW.

Other AUv3s built on another computer will also not show up. I have access to several Macs and for some unknown reason, randomly, 1 or 2 of the AUv3s will work on some machines but not others.

It’s very inconsistent.

Is there a way to rebuild the AUv3 cache on a machine ?
Is there a way to use AUVAL to test an AUv3 while ignoring any AUs that may share similar properties ?
Is there a surefire way to install an AUv3 on a target machine ?

Thanks.
Mark


#2

The AUv3 gets registered when you use the Finder to launch the standalone app which contains the AUv3 appex bundle (i.e. double-click on the standalone app’s icon in the Finder).

Additionally, it will only register when both the standalone app and the appex bundle is code-signed. The AUv3 appex must have it’s sandbox compatibility enabled (which the Projucer will do for you automatically).

Additionally, on macOS High Sierra, you also need to reboot after this.

Logic Pro X also needs you to re-scan plug-ins and check the USE AUv3 mode checkbox in Logic’s Plug-in manager.


#3

Thanks !
The High Sierra restart ‘trick’ was helpful.


#4

Update 1 -
PackageMaker.app related issues:
Turns out using PackageMaker to install applications (not just plug-ins) was part of my problem.

  • Renaming my app “something_a.app” solved one problem, where “something a.app” (note the space) would not install properly. Oddly, “something else.app” works fine.
  • When adding an app to a PackageMaker session, the applied defaults are different than for plug-ins. So, manually disabling the two checkboxes was critical for me:
    • “Allow Custom Location”
    • “Allow Relocation”
      WARNING: the second checkbox “Allow Relocation” would automagically turn itself back on randomly from time to time - so, checking it’s state for each build is necessary.

#5

Update 2 -
Info.plist related issues:
My bad. In some of my plug-ins the info in the plist file for subtype was different than the integer representation held in the AppConfig.h file’s JucePlugin_PluginCode.
Sidenote: this also seemed to help with an issue where too many instances of a plug-in were showing up in a DAW’s plug-in menu.


#6

Update 3 -
Container app issues:
I had at least 2 copies of each app littering my hard drive. So modifying the Xcode build settings allowed me to build in-place and limit each app to a single copy. Plus, the app’s build location is the same as its deployment location. This seemed to help…

In Xcode, build settings, deployment:

  • change DEPLOYMENT LOCATION to ‘YES’
  • change INSTALLATION BUILD PRODUCTS LOCATION to ‘/’
  • change INSTALLATION DIRECTORY to ‘/Applications/’

#7

Update 4 -
GarageBand may not see your AUv3 unless Logic Pro X uses it first.
Apparently, this is a known issue that Apple has not resolved.
Hack:
Open Logic’s plug-in manager, find your plug-in and select its AUv3 checkbox. This will auto-generate a *.tagset file keyed to your plug-in’s subtype and manufacturer 4 character codes.
Locate the *.tagset file in ~/Music/Audio Music Apps/Databases/Tags/ - it will be the one with the most recent creation date.
Add this file to your Xcode project’s ‘Standalone Plugin’ target. This will cause it to be copied into your bundle’s Resources folder when you build your AUv3 application container.
In PackageManager, add a POST build script that copies the *.tagset file from your app bundle’s resources to the user’s Tags directory.
NOTE: this is not a great solution. If someone runs your installer from one account (say admin) then, later, logs in from another account (say a standard account) and opens GarageBand there will be no local *.tagset file associated with your plug-in :frowning: