Re: AudioUnit: Open Times are too long
Re: AudioUnit: Open Times are too long
- Subject: Re: AudioUnit: Open Times are too long
- From: "Michael Olsen" <email@hidden>
- Date: Sat, 26 Apr 2003 11:04:08 +0100
- Organization: IK Multimedia
Ok, so we can defer initialization until someone either ask for a parameter info, or wants to show the GUI.
But please understand that the instant any of this happens, we have to create all our parameters, which, as previously explained, takes quite some time.
Believing that we can create our parameters one at a time is, I'm afraid, rather unrealistic.
Rgds,
Michael Olsen
email@hidden
>
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.