Re: AudioUnit: Open Times are too long
Re: AudioUnit: Open Times are too long
- Subject: Re: AudioUnit: Open Times are too long
- From: Bill Stewart <email@hidden>
- Date: Fri, 25 Apr 2003 14:43:48 -0700
Michael
I think you misunderstand my comments...
On Friday, April 25, 2003, at 01:39 AM, Michael Olsen wrote:
I think this will be a huge problem for SampleTank2. As far as I
understand, the host can query parameter info and get/set them before
initializing?
Well, SampleTank2 has 80.000+ parameters! It actually takes quite
some
time to setup our structures for this.
The parameter information is generally less of a concern for these
kinds of open and query mechanisms - generally the information the
host
wants to obtain from an AU are related around format issues (num
channels I/O, sample rates, etc...)
"Generally"? Does this mean that we should or should not be able to
deliver parameter info before initialize()?
By generally I mean that many clients won't care about parameter
information until the unit is in use. However, there are legitimate
means why an AudioUnit will need to have its parameter values both
settable and gettable before initialization. The different scenario
here is one where a user interacts with the AU in an app like Logic,
and the other where the app is using the unit (like a game engine for
instance).
Part of the problem however with the first scenario is that the host
may get the view or assemble what it needs to do with the AU for its UI
before it is initialized. Thus....
Furthermore we need to scan the instrument folder for instruments and
open the header files (the count can typically be in the thousands)
to
get instrument ID values. This is neccasary so we can react properly
on parameter changes (i.e. instrument load).
Any suggestions to what we can do?
As long as this is not done at Open time you should be OK.
So, the host is not allowed to set parameters before Initialize()?
We typically
have a lazy approach to initialization of values within structs, so
that you only pay the cost of activities when you need too.
I'm afraid you lost me there.
OK... Imagine you have this construct:
myParamInfoObj = NULL (in the constructor)
In Initialization:
CreateParamInfo();
Where CreateParamInfo is defined as:
void CreateParamInfo ()
{
if (myParamInfoObj == NULL)
myParamInfoObj = new ParamInfoObj;
}
Then in the property methods that get/set parameter info you can do
(say GetParamInfoList)
CreateParamInfo();
... get the param list
This is similar to the way that the element creation is handled (and is
part of the general cleanup that can be found in the SDK I've just
announce)
CreateElements is called from the PostConstructor because you need
elements for most operations that you would do before initialization
(like format stuff for instance)
So CreateElements will just create the state that is needed to capture
that information. Then in Initialization the actual buffers that are
needed on the elements are created for you.
In the sample effect unit we call CreateElements in the constructor
itself, then set the parameter values (which of course require the
elements to be created)....
If this is an onerous task to do and may not be required every time
someone opens you, then factoring out the creation of the parameter
info as described above is a reasonable compromise. Internally we have
a very strong emphasis on this pattern of programming - thus for
instance, we don't run ANY code in static initialization as this
contributes to the load time of a framework and thus penalizes the
launch time of every app on the system - often in unfair ways because
of all the static state you need, each app may only use a fraction of
it...
Does that make sense?
Well, yes, except that I naturally need the guarantee that this is not
called before Initialize(). It needs to be in the specs, so that we
don't get problems with other hosts.
I'm not prepared to make that commitment as i don't believe it is
necessary
Bill
Rgds,
Michael Olsen
email@hidden
bill
Rgds,
Michael Olsen
CTO
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
______________________________________________________________________
__
__
--
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.