Re: 2 AUCocoaView implementation questions: How to deal with uninitialized AU, and restrict Host to single view.
Re: 2 AUCocoaView implementation questions: How to deal with uninitialized AU, and restrict Host to single view.
- Subject: Re: 2 AUCocoaView implementation questions: How to deal with uninitialized AU, and restrict Host to single view.
- From: William Stewart <email@hidden>
- Date: Tue, 6 Jul 2010 14:36:37 -0700
On Jul 4, 2010, at 11:22 PM, Motti Shneor wrote:
> Hello everyone.
>
> 1. - How to deal with an uninitialized AU.
>
> In the Audio Unit Programming guide, Chapter 3 (The Audio Unit View) It is stated that a Custom AU View (Cocoa included) should be prepared
> to exist and function even when its related AudioUnit is uninitialized.
Yes. The reason being that Initialisation is aimed at doing the allocations necessary for rendering, but the basic AU state should be present from when the AU is opened.
> In our case, I must do some stuff (in the view instance) to support this --- I must disable some UI elements and shut down some UI timers .
ok.
> However --- There is no standard notification I am aware of that the Cocoa View gets, when it loses its AU.
Your view is destroyed. That is how you know that the view has been closed. However, there is no concept that the view exists AFTER the lifetime of the audio unit it is initialised with (though some hosts do have bugs in this area that have been fixed)
> The only time where the view gets to know its AU is
> upon Instantiation.
yes. It is a simple and straight forward model:
Open the AU
while (au is open)
view is created for AU
view is closed
(so, in the lifetime of an AU, it can have multiple views, these can be open sequentially by the user, or in parallel)
> Is there a standard way to do that?
> Should I establish a custom Property and AU Event to notify my view when the AU gets uninitialized?
If you need to know this state change, that is a fine idea. We don't have a standard property for this
> Should the Cocoa view poll on its AU for its state? when?
Ideally, no. Rather it should be driven by notifications of changes to its state, so the use of custom properties is a fine idea. If knowing when an AU is initialised (or not) is good, then we could add a property as a formal mechanism to do that (if you would like this, please write a bug). It would be something like: kAudioUnitProperty_IsInitialized
Bill
_______________________________________________
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