When a host application opens an audio unit, it can query the audio unit as to whether it has a custom view. The host does this with code such as this snippet from the CocoaAUHost project in the SDK:
Listing 3-1 A host application gets a Cocoa custom view from an audio unit
if (AudioUnitGetProperty ( |
inAU, // the audio unit the host is checking |
kAudioUnitProperty_CocoaUI, // the property the host is querying |
kAudioUnitScope_Global, |
0, |
cocoaViewInfo, |
&dataSize) == noErr) { |
CocoaViewBundlePath = // the host gets the path to the view bundle |
(NSURL *) cocoaViewInfo -> mCocoaAUViewBundleLocation; |
factoryClassName = // the host gets the view's class name |
(NSString *) cocoaViewInfo -> mCocoaAUViewClass[0]; |
} |
If you do not supply a custom view with your audio unit, the host will build a generic view based on your audio unit’s parameter and property definitions.
Here is what happens, in terms of presenting a view to the user, when a host opens an audio unit:
The host application calls the GetProperty method on an audio unit to find out if it has a custom view, as shown in Listing 3-1. If the audio unit provides a Cocoa view, the audio unit should implement the kAudioUnitProperty_CocoaUI property. If the audio unit provides a Carbon view, the audio unit should implement the kAudioUnitProperty_GetUIComponentList property. The rest of this sequence assumes the use of a Cocoa custom view.
The host calls the GetPropertyInfo method for the kAudioUnitProperty_CocoaUI property to find out how many Cocoa custom views are available. As a short cut, a host can skip the call to GetPropertyInfo. In this case, the host would take the first view in the view class array by using code such as shown in the listing above, using an array index of 0: factoryClassName = (NSString *) cocoaViewInfo -> mCocoaAUViewClass[0];. In this case, skip ahead to step 4.
The audio unit returns the size of the AudioUnitCocoaViewInfo structure as an integer value, indicating how many Cocoa custom views are available. Typically, developers create one view per audio unit.
The host examines the value of cocoaViewInfo to find out where the view bundle is and what the main view class is for the view (or for the specified view if the audio unit provides more than one).
The host loads the view bundle, starting by loading the main view class to instantiate it.
There are some rules about how to structure the main view class for a Cocoa view:
The view must implement the AUCocoaUIBase protocol. This protocol specifies that the view class acts as a factory for views, and returns an NSView object using the uiViewForAudioUnit:withSize: method. This method tells the view which audio unit owns it, and provides a hint regarding screen size for the view in pixels (using an NSSize structure).
- (NSView *) uiViewForAudioUnit: (AudioUnit) inAudioUnit |
withSize: (NSSize) inPreferredSize; |
If you’re using a nib file to construct the view (as opposed to generating the view programmatically), the owner of the nib file is the main (factory) class for the view.
An audio unit’s view should work whether the audio unit is simply instantiated or whether it has been initialized. The view should continue to work if the host uninitializes the audio unit. That is, a view should not assume that its audio unit is initialized. This is important enough in practice that the auval tool includes a test for retention of parameter values across uninitialization and reinitialization.
Last updated: 2007-10-31