Re: so, just what is the intended purpose of "subtype" for an AU plugin?
Re: so, just what is the intended purpose of "subtype" for an AU plugin?
- Subject: Re: so, just what is the intended purpose of "subtype" for an AU plugin?
- From: Paul Davis <email@hidden>
- Date: Mon, 15 Mar 2010 21:39:01 -0400
On Mon, Mar 15, 2010 at 8:43 PM, William Stewart <email@hidden> wrote:
>
> On Mar 12, 2010, at 8:07 AM, Paul Davis wrote:
>
>> On Fri, Mar 12, 2010 at 11:00 AM, Paul Davis <email@hidden> wrote:
>>
>> [ ... ]
>>
>> following up on my own email, i realized something just after i sent
>> it. the convention in AU land appears to be that a plugin is uniquely
>> identified by the triplet of "type-subtype-manufacturer". given that
>> most plugins are FX, type is fixed as "aufx", and the manufacturer is
>> a given. thus, to uniquely a given plugin from a particular
>> manufacturer, subtype has to be a plugin ID, not a "type of plugin".
>>
>> apple gets away with this for their own plugins because they only make
>> 1 of any given type of plugin, or, when there is more than instance,
>> they differ in the "type" field, eg:
>>
>> aufc tmpt appl - Apple: AUTimePitch
>> auol tmpt appl - Apple: AUTimePitch
>>
>> this means that "subtype" cannot possibly play the role described by:
>>
>>> "In the file system, an audio unit’s loadable code is contained in a
>>> bundle. Each such bundle is uniquely identified by a triplet of
>>> four-char codes. The type code programmatically identifies what the
>>> audio unit is for—such as mixing or audio format conversion—and
>>> indirectly specifies the audio unit’s API. The subtype code
>>> contributes to the bundle’s identification and indicates more
>>> specifically what the audio unit does. For instance, the subtype of a
>>> mixer type of audio unit might indicate that it is a multichannel
>>> mixer."
>>
>> was this just a thinko in the design of AU?
>
> There is some confusion in the documentation you cite here.
Thanks for the clarification. For the record, the documentation I cited was:
http://developer.apple.com/iPhone/library/documentation/Audio/Conceptual/AudioUnitLoadingGuide_iPhoneOS/AboutAudioUnitAccess/AboutAudioUnitAccess.html
It is true that this document:
http://developer.apple.com/mac/library/documentation/MusicAudio/Conceptual/AudioUnitProgrammingGuide/AudioUnitDevelopmentFundamentals/AudioUnitDevelopmentFundamentals.html
provides a clearer statement about hosts using subtype info:
>The “subtype” describes more precisely what an audio unit does, but is not programmatically significant for audio units.
>
>For example, Mac OS X includes an effect unit of subtype 'lpas', named to suggest that it provides low-pass filtering. If, for your audio unit, you use one of the >subtypes listed in the AUComponent.h header file in the Audio Unit framework (such as 'lpas'), you are suggesting to users of your audio unit that it behaves like the >named subtype. However, host applications make no assumptions about your audio unit based on its subtype. You are free to use any subtype code, including >subtypes named with only lowercase letters.
I know its not a high priority but it might be useful to bring these
two "introductory" documents into alignment with each other. Its clear
that more or less no manufacturer uses the subtype with reference to
the AUComponent.h header file, so mentioning that in this context is
also pretty confusing.
thanks again.
--p
_______________________________________________
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