Well, this has to do I suppose with changes in the AudioComponentRegistrar. The changes were made to allow audio units that are not bundles, that is, AUv3, which are XPC services, to be discoverable by the system, since they live in the container app’s bundle and not in a predetermined folder the system can just look for.
Of course, for iOS, plugins cannot be bundles due to sandboxing, and must rely on inter-process communication. But for macOS there are options. Unfortunately the changes to the AudioComponentRegistrar affected everyone, including AUv2. Many people have complained over the years about this, since dropping an AUv2 into the Components folder may take a restart for Logic to see the audio unit. One can force the AudioComponentRegistrar to reload as a post-install script step of an AUv2 installer. That would be unwise, though, for a variety of reasons. I haven’t seen problems in iOS, but Bram Bos has and it can have a bad effect on sales and user trust. Wishing you all a great week, Luis ________________________________ From: Bram Bos via Coreaudio-api <[email protected]> Sent: Monday, October 26, 2020 9:46 AM To: coreaudio-api Subject: Re: Logic does not recognise AU plugins until OSX restart. [External Email] I'd be very interested in knowing the solution to this issue. It happens in iOS as well: new customers contacting me that the newly installed AUv3 doesn't show up in any host. In 99% of the cases a restart solves it, but by then some will already have left a 1-star review with a message that the app doesn't work 😕 ________________________________ From: audio boy via Coreaudio-api <[email protected]> Sent: Monday, October 26, 2020 3:15 AM To: coreaudio-api <[email protected]> Subject: Logic does not recognise AU plugins until OSX restart. Having googled, this does seem to be a long standing problem and we are not the only vendor to be affected by this. However it's clear from user reports that many AUs are not affected by this and show up correctly after install. So I would really like to figure out finally exactly why this happens. Does anyone know what the official mechanism is? There doesnt seem to be anything on it in the apple docs. What might be relevant is that we dont put our AU properties (type, subtype) etc in the plist, only the .R file, as a result, we are using the older entry point mechanism. But several major vendors, such as U-HE are also doing the same, having checked, and these plugins show up fine after install, at least on my test machine. Also as you may have seen in my other recent post, we have set an invalid SubType code (a number instead of a valid FourCC). Could this be a reason? (But we are unable to change this as doing so makes our plugins apparently disappear from Logic). Would really really like to finally solve this problem.... Thanks _______________________________________________ Do not post admin requests to the list. They will be ignored. Coreaudio-api mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/coreaudio-api/brambos%40outlook.com<https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.apple.com_mailman_options_coreaudio-2Dapi_brambos-2540outlook.com&d=DwMGaQ&c=sJ6xIWYx-zLMB3EPkvcnVg&r=Bjp8G2_PTZ-F4j8pugVlzQ&m=k0O8rh-zE7LyRTeSQgkuiXTHn9S3xvlAo2HlpIZQ0WI&s=6onbxWKPBBCgkxCuKsPtjf-2XJ05OH1fYOf0MLhRGNk&e=> This email sent to [email protected]
_______________________________________________ Do not post admin requests to the list. They will be ignored. Coreaudio-api mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/coreaudio-api/archive%40mail-archive.com This email sent to [email protected]
