| Thanks, Ian. I will keep this advice in mind. Especially good to know about the possible failure of commercial apps to support the Cocoa UI property. In my case it will not be an issue because I'm writing a GarageBand specific unit, but I am definitely glad to know about that risk for the future.
In case anybody is curious (or still has good warnings to offer!), what I've done is establish a custom property on my audio unit that returns the "unit controller," an Objective-C class whose task it is to manage properties of the Audio Unit. By exposing this through the AudioUnit API, I'm able to ask for it from my Cocoa view class, which in turn exposes it to the Nib-based AI through a single "auController" keyed value. The Nib then contains a bindings controller object connected to the view's auController. The auController property is dependent on the audio unit (setAU), so whenever it changes, the corresponding auController object changes and consequently repopulates the Cocoa UI.
Through this arrangement, I'm able to bind all of my UI values to the audio unit. I understand that I've thrown flexibility for a future non-Cocoa view out the window, but I don't anticipate that happening, and if it does I'll have to write a new straight-C layer on top of my Cocoa model, anyway.
The main concern I have now is whether I'm jinxing the "preset" concept by doing all of my configuration behind CoreAudio's back. I've seen some references in the archives about having to expose at least one Parameter in order to get presets functioning correctly. I will have to cross the bridge (if it exists!) when I get there :)
I can imagine readers now thinking "you should publish your parameters through the standard mechanism so that other applications have a generic interface to it." In this particular case, you'll just have to believe me that we don't want other applications having that kind of control. So in a sense, it's a bonus to us that it can't be used that way.
Daniel On Jan 30, 2006, at 3:52 PM, Ian Kemmish wrote: The Audio Unit API is a "thinnish"-wire protocol, and it's good to keep that if you can. I think Objective-C has a bunch of classes to do with RPC (though I've never used them); maybe you can use those to implement a richer protocol than the basic one without needing to pass pointers around.
A word of warning though - I've just spent two years doing a MusicDevice AU with a Cocoa UI, only to discover that the first commercial host I've tested it with, Digital Performer, appears not to support AU's with Cocoa UIs. At least, it doesn't bother to query the AU's kAudioUnitProperty_CocoaUI property, and MOTU's support department have not got back to me yet. So if you're developing an AU that you hope to use with commercial hosts, you may want to take that into consideration.
|