AU Manifesto (was Re: AUView opening before initialzation BIG HASSLE!)
AU Manifesto (was Re: AUView opening before initialzation BIG HASSLE!)
- Subject: AU Manifesto (was Re: AUView opening before initialzation BIG HASSLE!)
- From: Bill Stewart <email@hidden>
- Date: Mon, 8 Sep 2003 12:30:10 -0700
OK - well I'm going to describe what our implementation does, why it
does this, and where I think the main problems are with current
implementations. I'll try to make this brief and concise.
The AUBase implementation was designed to hold ALL of the state of an
AU. Much of the functionality of the properties and parameters are
handled by these set of classes.
NONE of this state is dependent on whether the AU is initialized or not.
So, what is the difference?
The intention through this implementation was to separate the state
machine of the AU with its render state. When initialized, the
intention was to at that time, allocate resources (like delay lines,
etc) that are needed for Rendering. It was *NOT* the intention that an
AU's parameter state (or any of its state expressed by properties)
would also be allocated at that time - at least in the majority of AU's.
Through this separation, the base classes are able to maintain
parameter values (and to dispatch rendering based on both intra-buffer
parameter changes, ramped parameter changes, etc), and to both save and
restore an AU's state. The intention here is that the base classes
would provide all this work with *NO* need for developers to change
this. We had expected that developers could use *all* of this code, and
just have to deal with the really hard part of writing their DSP.
In recognition that there is already substantial bodies of code out
there that do not honour this separation (some of these for valid
reasons of course) we've allowed an AU to return
kAudioUnitErr_Uninitialized from parameter calls. I have some regrets
about this (as I see this becoming a standard, not exceptional
practise). This basically leads to a blurred distinction between:
(1) General AU state - an Open AU
(2) Render AU state - an Initialized AU
We had originally thought of this 'exception' as being only applied in
some special cases - for instance, the Matrix Mixer uses elementID to
discriminate Global, Input, Output, Cross-Point volumes and uses the AU
API with a slightly different semantic than an effect or a music device
AU.
Our reference implementation supports this separation.
To my mind, a host that does this:
Open an AU
set a couple of standard properties (like formats)
Initializes an AU
sets the remaining properties
Is in many ways basing its usage of an AU as if it were a similar
entity to other plug in formats that do not provide for this
distinction. By this I mean, that an AU should (at least in the spirit
of its design) be totally configurable by a user without requiring
either initialization or rendering. Thus:
Open an AU
Configure it... (including UI)
You have to render? I'll Initialize the AU...
If an implementation is not using, or circumventing the reference
implementation we publish in the SDK, then we would hope that that
implementation is honouring the spirit of the AU design. In many cases
this is not the case unfortunately, and we are doing our best to work
through these discrepancies.
I think we fully acknowledge that we haven't explained ourselves as
completely as we could (and I think in some part we've been blinded by
our own familiarity and assumptions that this would be used by others).
To address this we've developed the validation tool to make explicit
the expectations that are implicit in our implementation as well as to
acknowledge that our implementation is not the only one, and that
others deal with constraints that imply that our assumptions cannot be
used as a basis for theirs.
To try to make this more explicit we will include some examples in the
SDK of how we implement our AUs - by subclassing the kernels for
effects, by having these render kernels call back into the AU to get
parameter values at render time, etc... in short, to keep the different
state where we think it belongs.
We also I think need to provide a better base class for music devices,
though given the present situation with effect units, I'm not sure if
we did this, that many developers would use it.
I think to try to improve the validation tool, I'll add a -strict
option that will *not* accept effects or music device AUs returning a
requirement to be initialized- and maybe after a period of time, we can
actually make this a requirement for a compliant AU.
Bill
On Monday, September 8, 2003, at 05:18 AM, Urs Heckmann wrote:
Angus,
you're in kinda big dilemma. You're a host manufacturer and a plugin
developer 8-))
I'm just a plugin developer and an advocate of AU's beauty. I want
hosts and plugins to behave correctly in order to avoid the stuff you
see all day. If my interpretation of the specs is incorrect, I'll fix
my stuff. But if my interpretation is correct, I want to see it work
that way, everywhere.
Most of the times, when confusion like that comes up, due to an
uncertainty, some people at CoreAudio team start mumbling, and they
come up with a verdict. This is important, to keep the standard clean.
The case that I experienced might happen only 1 out of 10000 times, by
sheer coincidence and circumstances. So most plugin developers may not
even experience this certain problem, until 2 months after a plugin
release a crash occurs, maybe live on stage during a Britney Spears
concert.
If there's certainty, this case can hopefully be prevented, both on
plugin side and/or host side.
Well, maybe I'm just confused that a lot of hosts already treat some
stuff "their own way". I think I'll use AUHosting as reference and add
it to my plugin distribution. Hence I'll offer stand alone versions of
my plugs that might or might not work with any other host :-b
Cheers,
;) Urs
Am Montag, 08.09.03, um 12:41 Uhr (Europe/Berlin) schrieb Angus F.
Hewlett:
Can you not just call Initialize() (or better, an internal initialize
method) from your plug when you run in to a problem? That's what I do
in
VST-AU:- if it is possible for it to complete a call without
Initialize()ing, it does so, but if it has to intialize those things,
it
does that instead. Equally, in the view class, I don't instantiate
anything
big until I need to create and display the view.
The downside of this approach is that it makes host load times a bit
unpredictable... depending on what the host asks for when scanning
plugins,
it may take a couple of ms per AU or a few hundred ms (many VST
plugins are
slow to load). I could improve performance some more by caching more
information than I currently do (the output configuration is cached;
the
audio I/O properties are cached; the parameter table is not).
Regards,
Angus.
At 03:27 PM 9/7/2003 +0200, Urs Heckmann wrote:
Hi,
I have a Music Devcie that publishes its parameters and stuff after
Initialization. This is legal, as far as I know. Before init, I
return
an UnInitialized error on these requests.
A certain host sometimes opens the view before initializing the music
device. And that leads to a crash, because important stuff isn't set
up. (Even if I circumvent these crashes, the gui would just not
happen.
Void.)
How can I tell the host not to open the gui before initialization? -
Wouldn't publishing parameters and stuff AFTER init first implicitly
forbid opening the view?
Cheers,
;) Urs
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.
=======================================================
Angus F. Hewlett, Technical Director
FXpansion Audio UK Ltd - http://www.fxpansion.com
=======================================================
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.
--
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
________________________________________________________________________
__
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.