AU plug-in requires a copy in /Library

[RolandSchuetzenhofer]

When opening a plug-in with Test File pluginval fails immediately with

Validation started
	24 Jan 2024 3:28:23pm

Strictness level: 10
-----------------------------------------------------------------
Starting tests in: pluginval / Scan for plugins located in:  /Users/User/build/Plugin/Plugin_artefacts/Release/AU/PlugIn.component...
Started validating:  /Users/User/build/Plugin/Plugin_artefacts/Release/AU/PlugIn.component
Num plugins found: 0
!!! Test 1 failed: No types found. This usually means the plugin binary is missing or damaged, an incompatible format or that it is an AU that isn't found by macOS so can't be created.
FAILED!!  1 test failed, out of a total of 1

Finished validating: /Users/User/build/Plugin/Plugin_artefacts/Release/AU/PlugIn.component
*** FAILED WITH EXIT CODE: 1

Finished batch validation

When there's a copy of the .component in /Library/Audio/Plug-Ins/Components, Test File works as expected.

This becomes a problem when using pluginval in a CI pipeline, as we don't want to (or even can't) copy the .component to the system's components folder.

Tested on
Sonoma 14.2 & Sonoma 14.3.

[drowaudio]

I think this is just a limitation with macOS. It's impossible to load an AU until it's been registered with the AUComponentManager and that happens when you move it on to the correct location. It's not something we have control over.

[2-shell]

@RolandSchuetzenhofer Not a real solution, but you might be able to use ~/Library/Audio/Plug-Ins/Components (i.e. the user-specific variant instead of the system-wide).

With a dedicated user account for testing, that would at least lift the burden of requiring superuser rights to do the copying and avoid system-wide changes.

At least that's what we do, when running auval directly in CI.

Note, that we also do a sh -c "killall -9 AudioComponentRegistrar || true" after the copying, to make sure the plugin is discovered, which (at least for us) works without superuser rights as well.