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: Motti Shneor <email@hidden>
- Date: Sun, 18 Jul 2010 08:28:41 -0400
- Acceptlanguage: en-US
- Thread-topic: 2 AUCocoaView implementation questions: How to deal with uninitialized AU, and restrict Host to single view.
Thanks Bill!
This is very helpful. I still need few more clarifications (see below) but I will probably establish a custom property for notifying our Cocoa AUViews of their AU's initialization state changes.
On 07/07/2010, at 00:36, William Stewart wrote:
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 Initialization 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 --- much of the UI state is only available FROM the AU, AFTER it is initialized (to be painfully specific, our cross-platform UI description system is loaded upon initialization of the AU in the AU). Should a Waves AU be opened, then its related Cocoa view opened when the AU is still uninitiated --- the view must KNOW that and change its appearance accordingly.
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)
Pardon me --- But what happens first? is the AU uninitialized first, then its view closed and deallocated, or the other way round?
This is important for us because of the strong connection of our View and AU. There are several objects shared between the two entities, whose ownership is not clear to us.
As you say --- there is no concept that a view exists after its AU was closed --- but there is nothing to prevent that --- If for instance our AU gets uninitialized (not even closed!) our Cocoa view will still try to talk to it.
Moreover, In AU-Lab the ONLY time I got my Cocoa AU-View deallocated was when the AU was "removed" from the session. Closing the View (pressing its close-box) does NOT release it, and even Quitting AU-Lab altogether, I don't get to the "dealloc" of my Cocoa View. What's the rule here?
1. We may have resources we should release when a view is closed (hmmm.... think of communication with software-protection drivers) and close some files, etc.
2. It is very useful (performance wise) for our View to know when it is not visible. What should I override? what should a Host do, and specifically, what does AU-Lab when the user closes the view?
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)
As I stated, our specific implementation cannot currently support more than one view (instance!, not class) per AU. This is because they share some mutual state object (weird but that's how it is now). Even if we DID support more than one view per AU, we must limit this to a certain number for performance reasons (some AU's we sell are very sensitive to view-refresh rates, and maintain tight synchronization with the audio, so they can't afford more than few views).
For that, I must have a way to REFUSE opening a new view instance, and a way to know how many view instances exist for an AU. In the old Component-Manager days, I could write a simple generic code to question the system on this, (Specify a component via type sub-type and vendor, then iterate its instances). But How can I do this for Cocoa views? where there is no registry?
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
OK. I'll open a bug soon about this. I think there are more AU states that are useful to its view.
Thanks again ---
Motti Shneor
------------------------------------------
Senior Software Engineer
Waves Audio ltd.
Phone: +972-3-6084155
Mobile: +972-54-4470730
[mailto: email@hidden]
_______________________________________________
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