Re: Cocoa-Heavy Audio Unit
Re: Cocoa-Heavy Audio Unit
- Subject: Re: Cocoa-Heavy Audio Unit
- From: William Stewart <email@hidden>
- Date: Mon, 30 Jan 2006 15:07:12 -0800
On 30/01/2006, at 1:26 PM, Daniel Jalkut wrote:
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.
Firstly, there is no such thing as a "this app, or that app" specific
AudioUnit. AudioUnits are a platform standard and any host of a
particular AU type (be it an effect, instrument, converter, etc) will
see and can use your AU.
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'm not entirely sure what your concern is. The choices you make
about implementation are your own.
AUs are explicit about their expectations, and host applications
build their handling of AUs based on those expectations. Primarily,
those expectations are that parameters of your AU that should be
published are (so that host apps can automate, draw generic UIs,
etc). AU Presets are a predefined data format that is used to save
and restore the state of an AU (for instance, GB like other host
apps, uses this in its project files). As we've explained what goes
into an aupreset is AU dependent.
auval tests as much of this as it can and along with every other
developer, your AU is expected to pass this validation process.
We've been strongly advising developers for many years now not to
assume that the view and the AU are executing within the same address
space. We continue to maintain that position. The AUFilter demo we
provide in the SDK provides an example of how private data can be
shared between an AU and its view.
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."
Well, yes, we do expect that. This is an integral part of the AU spec
and not one you are free to ignore. There is no prescription about
how many parameters an AU has to publish.
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.
That's a different decision and different reason (user experience)
than a justification based on a preferred implementation design
(which seems to be your current topic). So, I'm actually a little
confused about what you are asking exactly...
Bill
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.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
--
mailto:email@hidden
tel: +1 408 974 4056
________________________________________________________________________
__
"Much human ingenuity has gone into finding the ultimate Before.
The current state of knowledge can be summarized thus:
In the beginning, there was nothing, which exploded" - Terry Pratchett
________________________________________________________________________
__
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden