Re: kAudioUnitProperty_ContextName
Re: kAudioUnitProperty_ContextName
- Subject: Re: kAudioUnitProperty_ContextName
- From: William Stewart <email@hidden>
- Date: Tue, 27 Jul 2004 09:25:12 -0700
We also looked at this recently and realised that AUBase doesn't
support this (and that it isn't documented either). So, we'll add
support to this in AUBase before we revise the SDK.
On 27/07/2004, at 4:27 AM, Stefan Gretscher wrote:
>
Am 20.07.2004 um 21:04 schrieb Marc Poirier:
>
> The kAudioUnitProperty_ContextName seems like a nice idea and useful,
>
> though unfortunately also seems to be a neglected corner of the AU
>
> API.
>
I'll try to add support for this to Logic soon, but we'll need to
>
answer your questions first. :-)
>
>
Here's how I'd suggest kAudioUnitProperty_ContextName should be
>
handled:
>
>
> 1) Should the text (the property's value) include the AU's name plus
>
> extra context info, or only the extra context info? In other words,
>
> let's say for example I had the plugin "Robocop FX" inserted on track
>
> 3. Would a possible ContextName be something like "Robocop FX: track
>
> 3" or just "track 3"?
>
In my opinion it only should contains "track 3", because each AU knows
>
its name and can add it or not as applicable. Adding strings is easier
>
then removing the name to get the pure context string.
The AU shouldn't care what is in the String and furthermore the AU
shouldn't modify the string in any way. So either approach would be
appropriate but I would think the common usage would be to just set the
"track 3" string, rather than the full name (however, if you have
localised names, it might also be common usage to store the entire
string) - either way it shouldn't matter for the AU.
>
> 2) ContextName is not covered in CF_AU_Properties.text nor are its
>
> CoreFoundation semantics covered in the regular docs for the AU API:
>
> /Developer/Documentation/CoreAudio/AudioUnits/Topics/
>
> au_properties.html#kAudioUnitProperty_ContextName
>
> I am guessing that it is the norm (the AU creates or retains the
>
> value for the client on GetProperty, and retains the new value on
>
> SetProperty), but it seems to me like this should be explicitly
>
> stated somewhere.
>
I'd definitely vote for following the norm.
When the property is Set - the AU should retain the string (so
ultimately it might have the only reference to it).
When the property is retrieved, the AU should also retain the string,
so it always has a retain on the string it is holding. The host should
release the string it retrieves from Get Property when it is finished
with it.
The property can be cleared by setting the property with a NULL value
(so the AU *has* to check for NULL before retaining the value when the
property is set)
>
> 3) If the property's value has not yet been Set but someone tries to
>
> Get it, is the correct behavior for the AU to supply a null
>
> CFStringRef and return noErr, or to return an error? And if an
>
> error, which one?
>
I'd say returning a NULL ref seems appropriate, indicating "context
>
not defined".
If we agree that NULL is a valid value for the property to return, then
the host always has to check the string to see if it is NULL.
If the property is not implemented (as today in most AU's) then the AU
would return an error: kAudioUnitErr_InvalidProperty
I think it would be better if the current value of the property is NULL
for the AU to return:
kAudioUnitErr_InvalidPropertyValue
That way, if noErr is returned the host knows that the string returned
is valid and doesn't have to check for NULL?
Bill
>
It should also be legal for a host to set a NULL ref here to clear the
>
context.
>
>
That's just my opinion, let's see what others think.
>
>
Stefan
>
_______________________________________________
>
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
________________________________________________________________________
__
Culture Ship Names:
Ravished By The Sheer Implausibility Of That Last Statement [GSV]
I said, I've Got A Big Stick [OU]
Inappropiate Response [OU]
Far Over The Borders Of Insanity And Still Accelerating [Eccentric]
________________________________________________________________________
__
_______________________________________________
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.