Re: AudioUnit life cycle
Re: AudioUnit life cycle
- Subject: Re: AudioUnit life cycle
- From: Bill Stewart <email@hidden>
- Date: Mon, 07 Oct 2002 16:17:13 -0700
on 5/10/02 6:12 PM, Urs Heckmann wrote:
>
Hi,
>
>
I attach a message I sent to carbon-development list, but it contains
>
some issues that might be better answered here.
>
>
What I know so far from Logic and AudioUnitHosting, the AUCarbonView
>
class gets constructed/destructed everytime a plugin window is
>
opened/closed. Is that for sure in every host? - Or do they have other
>
means to close/open again a window? (Like keeping the mCarbonPane
>
hidden in astral data heaven)
If this can be done with Carbon, then the AUView should not have a problem
with this.
>
Next issue is static data. - Will that always be shared by every
>
instance of an AudioUnit? If so, will static data get lost when every
>
instance of an AudioUnit is disposed (i.e. when in Logic all instance
>
will be replaced by others or no effect)?
Yes - by every AU IN THE SAME PROCESS...
Static data for a class is like static data in a compile unit - once its
there it is there until the code itself is unloaded - it really has no
connection with any instance of a class itself.
Bill
>
Or are hosts supposed to load any AU at startup and then just
>
instantiate as needed without ever releasing the component's code +
>
static data?
>
>
Then, what if a second app uses that AudioUnit?
>
>
Any comment appreciated,
>
>
cheers,
>
>
;) Urs
>
>
>
here's that message:
>
>
> Hi,
>
>
>
> I'm implementing custom controls via RegisterToolboxObjectClass(). I
>
> give those a CFString like CFSTR ("com.Urs.UrsCtrl.cntrl"). This is
>
> not a big problem, but how do I know if such a control has already
>
> been registered? - Is there any chance to find out if an Object of
>
> that kind already exists?
>
>
>
> Situation is, the code that needs to manage this resides in a plugin
>
> (an AudioUnit, to be precise) that can be instantiated and disposed
>
> several times by a host application.
>
>
>
> Whenever an instance is set up, the control gets registered with a new
>
> ControlRef, right?. That way, the old one instantiated by an older
>
> instance gets "lost" along with the EventHandlerUPP (not really, I
>
> called latter static, but don't know if that is elegant or secure at
>
> all).
>
>
>
> I would prefer to find out if a control of that kind has already been
>
> established and use that one instead of creating the same over and
>
> over again. - Unfortunately I'm even not quite sure if static data
>
> will be shared by every instance of the plugin in every host
>
> application.
>
>
>
> Any ideas or functions I have overseen?
>
>
>
> 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.
--
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.