Re: Newbie AU questions (AU types and subtypes)
Re: Newbie AU questions (AU types and subtypes)
- Subject: Re: Newbie AU questions (AU types and subtypes)
- From: "B.J. Buchalter" <email@hidden>
- Date: Wed, 18 Sep 2002 15:08:33 -0400
>
on 18/9/02 2:30 AM, Paul Kellett wrote:
>
>
> Bill Stewart <email@hidden> wrote:
>
>>
>
>> We would really like to maintain a list of sub-types that implementors of
>
>> specific types of dsp would conform to.
>
>>
>
>> For instance, a reverb effect could be identified by the
>
>> kAudioUnitType_Effect and the kAudioUnitSubtype_Reverb
>
>>
>
>> Then - different manufacturers provide different implementations of this
>
>> that in many cases would report similar parameters, etc...
>
>
>
>
>
> As B.J. Buchalter said, that either limits each manufacturer to one
>
> effect of each type, or the subtype field will quickly stray away from
>
> Apple's list of subtypes and be of no use for sorting effects by their type.
>
>
Yes - and I think we'll have to abandon this idea, as the subtypes are
>
really the only field that any company (including us) can use for multiple
>
units.
>
>
So - my guess is that subtype can't realistically be used in this way
I think you are right. Especially since this is limited by the Component
Manager and cannot be changed.
But it would be a good idea to add an AU property that could be queried at
runtime that "Classifies" the effect type. Actually, it probably would make
sense to have a pair of properties -- a "effect type" (OSType) and an
"effect type" description (CFString). If the effect type is not defined then
the host would treat it as a generic audio effect. If it was defined and
used one of the standard Apple published types, the effect type description
would also be a standard Apple published ands localized CFString description
that a host could use to organize effects. If the effect had a non-standard
effect type (e.g. Not all lowercase), this would indicate that it was a
classified effect type, but not one covered byt the standard Apple types --
the CFString would be provided for UI purposes. The only reason a
manufacturer would use a non-standard effect type would be if they made an
effect that was not already classified, and expected to have multiple AU
that conformed to this type.
Obviously hosts could ignore the classification, or it could make it a user
pref. But if the metadata was available, it could be used for a number of
really cool UI enhancments:
Grouping plugs by type in popups.
Providing a quick idea of what a plug was for.
Enabling Hardware Control surface selection of plugs.
Finally, a manufacturer could use the non-standard effect type to group a
set of plugs into a suite for easy identification.
This could be added at any time to the API, and could probably be supported
by plug makers even before the API is ready as simple properties. Even
without an iteration API, the host implementor could query the property and
if it was defined could use it for sorting and classifying the list. It
retains the benefit of the original thought process without the small
namespace problem.
What do you all think about this concept?
Best regards,
B.J. Buchalter
Metric Halo
M/S 601 - Building 8
Castle Point Campus
Castle Point, NY 12511-0601 USA
tel +1 845 831-8600
fax +1 603 250-2451
If you haven't heard ChannelStrip yet, you don't know what you're missing!
Check out SpectraFoo, ChannelStrip and Mobile I/O at
http://www.mhlabs.com/
Download a 12 day demo from <
http://www.mhlabs.com/demo/>
_______________________________________________
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.