Audio Unit v3 / Extensions (OS X) in Logic Pro X

Hello!

I was wondering if the Audio Unit v3 API introduced last year is supported in Logic Pro X or any other major Host? So far I haven't gotten the sample Code working in Logic Pro X, it either doesn't seem to find the sample Filter AUv3 or it can find it but isn't able to load.


After doing looking through the release notes of the Logic updates since the announcement of the new AUv3 API, I wasn't able to find any hint that the new API is supported (also in no other forums).


It seems to me that the main focus of the Audio Unit v3 and Extensions API is to bring the whole AU world to iOS while the API is kind of being neglected on OS X (also by third party / plugin developers & companies)?

Replies

I’m kind of curious about the status on this as well. I read Logic release notes myself all the time and I haven’t seen it mentioned explicitly either. Having said that I downloaded the latest AUv3 sample code, compiled and ran both the instrument and the filter apps. Then launched Logic. Logic gave me an error saying one of the Audio Units couldn’t be loaded. I didn’t read the error message properly thinking it was reproducible, it wasn't 😟


Once inside Logic I was able to find and load the AUv3Instrument fine. And it worked too. However, I couldn’t find the Filter plug-in. I tried to look for it in the Plug-in Manager thinking that it would show it there saying that it had failed validation, but it wasn’t there. I couldn’t find the AUv3Instrument in the Plug-in Manager either. Which leads me to believe maybe AUv3 is not fully supported yet even though AUv3 instruments works.


I also tried them in GarageBand. To my surprise, both AUv3Instrument and Filter load and work fine there.

How did you manage the code signing of the Instrument and Effect to get them working in Garageband?


I can't seem to get either one working, always get the error that the plugin can't be loaded and to contact the manufacturer. Yet when I run the auval tool and test the Filter or Instrument there, it validates correctly and passes every test. Also in the AUHost that comes with the samples both work correctly.

Are you running the latest GarageBand and macOS (10.11.6)?

Updating to the newest version of GarageBand fixed this, now I can load both the Filter Effect and the Instrument.


However the sample code by Apple seems to be kind of incomplete, for the Filter Effect there seems to be no parameter automation support (I can't find any parameter when in automation), for the Instrument it seems to work. For both the Filter and the Instrument the persistance (loading/saving presets) also seems incomplete - while it is possible to save and load presets via the host, the view of the AUv3 plugin doesn't update accordingly.


edit: got both the Effect and Intstrument working in the most recent version of Logic (10.2.4) too. Same problems with automation and presistance.

It's good to hear you got it working. I'll have to investigate futher as to why Filter doesn't work for me in Logic when I have more time.


  • Regarding the automation, I tried Filter in GB and it does show me the Cutoff and Resonance as automatable parameters. Maybe double check that the kAudioUnitParameterFlag_IsWritable | kAudioUnitParameterFlag_IsReadable flags are set?
  • Regarding the UI refresh, make sure that the *allParameterValues* property of the AudioUnit is being observed via KVO. Your code should trigger the UI refresh when the KVO fires.

Thanks for your advice!


Little update: two weeks ago apple release a revision of their AUv3 Sample Code and added (factory) preset funtionality to their Filter Demo on OS X

np.

Yes, that's the version of sample code I'm using. I assumed you were using the same.

The Filter code demonstrates support for scheduled events and ramping which I've tested by modifying and playing around with the sample host app. The sample Filter AU however hasn't set the kAudioUnitParameterFlag_CanRamp flag for the parameters (this will be updated in the next release along with Swift 3 language updates as required and some other minor fixes), but maybe that's what Logic is looking for?


I'm also quite sure Logic support is still not complete for V3, so file bugs if you find host issues and our respective teams can investigate.


Presets and Views etc. have been tested in standard host code and should work as expected. Adding extensive logging to the sample, presets are changing parameters as expected and the observers are being called as expected. So, seems if the view isn't being updated it's going to be a host issue especially if a host is using a "Generic" parameter view which it creates on its own.


Feel free to do this yourself to confirm behaviors. Logging is also very helpful in bug reports.

A quick follow up question regarding the CanRamp flag. If a parameter is a switch type, i.e. it only has 2 discrete states: On or Off, setting the CanRamp flag for it doesn't make sense to me. The user should be able to automate the switch parameter, e.g. a bypass. So if Logic is looking for that flag that would mean it’s a bug, right? Or am I not understanding the purpose of the CanRamp flag correctly?

Right. So, I was referring to the FilterDemo v3 sample and its parameters. The DSPKernel helper class that comes with the sample handles both AURenderEventParameter and AURenderEventParameterRamp. For a simple on/off button I wouldn't expect a host render event asking for ramping that parameter, especially if the CanRamp flag wasn't set. In the sample, everything funnels though the startRamp(...) DSPKernel subclass method, but the AU can then handle the events as required.


The information arriving at the event handling code is via the AUParameterEvent.

/// Describes a scheduled parameter change.
typedef struct AUParameterEvent {
     union AURenderEvent *__nullable next;          //!< The next event in a linked list of events.
     AUEventSampleTime          eventSampleTime;     //!< The sample time at which the event is scheduled to occur.
     AURenderEventType          eventType;               //!< AURenderEventParameter or AURenderEventParameterRamp.
     uint8_t                         reserved[3];          //!< Must be 0.
     AUAudioFrameCount          rampDurationSampleFrames;
                                                            //!< If greater than 0, the event is a parameter ramp; 
                                                            ///       should be 0 for a non-ramped event.
     AUParameterAddress          parameterAddress;     //!< The parameter to change.
     AUValue                         value;                    //!< If ramped, the parameter value at the
                                                            ///     end of the ramp; for a non-ramped event,
                                                            ///     the new value.
} AUParameterEvent;

I have a short question. In which directory on Mac OS 10.12 should the App Extensions of the Filter and the Instrument demos be moved such that Logic Pro X can find them? What is the correct folder for Audio Unit V3 plug-ins now? Is it still /Library/Audio/Plug-Ins/Components?

Version 3 Audio Units are implemented as a subclass of AUAudioUnit and can be delivered as app extensions (you can also subclass AUAudioUnit and not make the AU available outside of your app if you choose). If you want to make the AU available as an extension, an app is used to contain and deliver your extension(s). Each extension is a separate binary that runs independent of the app used to deliver it. When a user installs your containing app, the extensions it contains are also installed and made available to other applications.


You don't move them into specific system folders, simply running the application once should register the extension with pluginkit. Use pluginkit -m from the console to list them, for example:


+    com.apple.ncplugin.weather(1.0)
+    com.apple.ncplugin.stocks(1.0)
!    com.example.apple-samplecode.FilterDemoAppOSX.FilterDemoAppExtensionOSX(1.5)
-    com.apple.share.Twitter.post(1.0)
+    com.apple.messages.ShareExtension(1.0)


For more information see the App Extension Programming Guide and for Audio Unit Extension specific information see the Audio Unit section of the same guide.

Thank you. I think I just did not understand that this is complete different approach than components. Now it is clear.

I have another question. Can you please tell me what would happen if you have both Audio Unit V2 and Audio Unit V3 plug-ins installed on a Mac. For instance, a plug-in is given on a system in Audio Unit V2 format with a specific identifier triple (TYPE, SUBT, MANU). And there is the same plug-in on the system with the identical identifier triple in Audio Unit V3 format. Which plug-ins are used by Xcode? Can the user decide whether he wants to instantiate a V2 or V3 plug-in? Or does Xcode always take the latest version only, so only the AUv3 plug-in can be instantiated?

There's header comments in AUAudioUnitImplementation.h explaining this. Doesn't really have anything to do with Xcode.


As of OS X version 10.12, the system has special support for installing both version 2 (bundle-based) and version 3 (extension) implementations of the same audio unit. When two components are registered with the same type/subtype/manufacturer and version, normally the first one found is used. But if one is an audio unit extension and the other is not, then the audio unit extension's registration "wins", though if an app attempts to open it synchronously, with AudioComponentInstanceNew, then the system will fall back to the version 2 implementation.