Re: AU custom cocoa view naming
Re: AU custom cocoa view naming
- Subject: Re: AU custom cocoa view naming
- From: Michael Hopkins <email@hidden>
- Date: Tue, 13 Sep 2005 10:03:27 -0700
Brian,
An interesting idea, but I'm not sure if that would be very useful.
The host loads the main class and then calls the description selector
on that class (which is an override of the NSObject selector of the
same signature), retaining the resulting string for display. It then
loads the view, and releases the main class. As long as it keeps the
view around, it can just also keep the view name string around. Once
it is finished with the view, it releases both it and the string.
If the description method was a class method, the host would need to
know what class to call +description on, so it would either need to
keep the class name around, or call get the main class from the audio
unit again. In either case, it is probably easier to just have stored
the string in the first place. Additionally, if the host would have
to check to make sure that it can call +description on the class.
Whereas, -description is guaranteed to be valid because it is an
override of NSObject's -description method which returns the class
name as the default behavior.
Hope this explanation makes sense. Thanks for your input.
-michael
On Sep 9, 2005, at 11:48 PM, Brian Willoughby wrote:
Hello,
Considering that the Cocoa AU Hosting sample code autoreleases the
mCocoaAUViewClass instance, wouldn't it be better if the
description method
were a class method?
+ (NSString *)description
{
return @"Filter View";
}
An instance method has the advantage of being able to return a
different
string based on the state of an individual plug-in instance, but if
the AU Host
has freed the mCocoaAUViewClass, then it won't be able to do
anything more
interesting than return a static string, in which case it should be
a class
method.
i.e. it is impossible for the host to call -description unless an
instance of
the factory class exists. +description could be called at any time.
Brian Willoughby
Sound Consulting
Begin forwarded message:
To: CoreAudio API <email@hidden>
From: Michael Hopkins <email@hidden>
Date: Thu, 8 Sep 2005 15:21:12 -0700
Subject: AU custom cocoa view naming
Hello everyone!
I would like to post a reminder for those of you that are writing
custom audio unit views in cocoa. Please make sure that your main
class (the entry point class in the mCocoaAUViewClass field of the
AudioUnitCocoaViewInfo structure, not your view class) implements the
description method. This method is used by hosts to display the name
of your custom view in your interface.
Example:
- (NSString *) description {
return [NSString withString: @"Filter View"];
}
If you do not override this method in your main class, the host may
use the name of your audio unit, or the name of your main class
instead. You can test your Audio Unit in a host such is AU Lab to see
how this string is used in a host application. Open the inspector
window for your audio unit and look at the popup menu in the upper
right hand corner of the inspector.
For more information, see WritingCocoaAUUIs.pdf in the CoreAudio SDK.
Thanks,
michael
_______________________________________________
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