Re: Newbie AU questions
Re: Newbie AU questions
- Subject: Re: Newbie AU questions
- From: Bill Stewart <email@hidden>
- Date: Tue, 17 Sep 2002 16:57:29 -0700
(Posting this response to the list - with permission)
on 17/9/02 4:06 PM, B.J. Buchalter wrote:
>
> on 16/9/02 3:31 PM, Marc Poirier wrote:
>
>
>
>>>> Ideally - an id that contains ALL lower case characters is reserved for
>
>>>> use by apple (So your ID could be ACME, Acme, aCME, etc but NOT acme)
>
>>>>
>
>>>> Not sure actually where you register the ID however...
>
>>>
>
>>> That would be at http://developer.apple.com/dev/cftype/
>
>>
>
>> Are you sure about that? It seems weird to me that you would
>
>> register a componentManufacturer code via the application creator
>
>> code registry. These codes do not serve the same functions at all
>
>> and I see no reason why there couldn't be duplication of codes
>
>> between the 2 types.
>
>>
>
>> One other question: Are all-lowercase componentSubType codes also
>
>> reserved by Apple, or is it only all-lowercase componentManufacturer
>
>> codes that are reserved? It will be a problem for VST -> AU
>
>> compatibility if all-lowercase subtype codes are reserved, since that
>
>> was not the case for VST plugin "unique ID" codes...
>
>
>
> 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...
>
>
It would seem that this sort of limits a Manufacturer to one implementation
>
of each effect sub-type, or a manufacturer will have to implement virtual
>
manufacturer codes. It would seem that we need:
>
>
The component type (set in stone)
>
The sub type (a common effect classification type)
>
The manufacturer code (a code for all plugs by a particular entity)
>
And a "flavor" type (which would be unique within the scope of a
>
manufacturer)
>
>
This way we could have
>
KAudioUnitType
>
kAudioUnitSubtype_Reverb
>
KAudioUnitManufacturer_MetricHalo
>
KMH_SamplingReverb
>
>
And
>
>
KAudioUnitType
>
kAudioUnitSubtype_Reverb
>
KAudioUnitManufacturer_MetricHalo
>
KMH_SimulatedReverb
>
>
And
>
>
KAudioUnitType
>
kAudioUnitSubtype_Reverb
>
KAudioUnitManufacturer_MetricHalo
>
KMH_RoomReverb
>
>
etc.
>
KAudioUnitType_Effect describes that it is an effect - but still you're
point is valid
>
Since KAudioUnitType is not really descriptive (e.g. It just identifies that
>
the component is an AudioUnit) and kAudioUnitSubtype is really being used as
>
a classification system, KAudioUnitManufacturer is not really enough --
>
because we will run into the VST namespace problem if that is all we have.
>
If we use the kAudioUnitSubtype as the manufacturer scoped id, we will
>
break the classification system. So it probably behooves us to get this
>
figured out early since there ought to be a bazillion audio units created in
>
the next little while....
I understand, but the component is (unfortunately) limited to a 3-field
limitation.
If you wish to keep the manufacturer field as an identifier for your company
(which you probably do) - then I see the only alternative being to describe
sub-types that combine both the reverb and its flavour...
I don't see this as too big a problem. These are typically used to describe
something unique so that the system can find them.
The most important part of this is that host apps can find the audio units
that are effects (thus of type kAudioUnitType_Effect)
Then, in common usage the user is presented with a list of names of units
that are of this type (and I would imagine that many hosts may order that
list based on the Manufacturer ID, rather than the effect type).
I don't see that the sub-types that we have defined have to be conformed to
(though if it is a simple case - like say here is my (ACME) digital delay -
then I think it is worth while doing this)
Once they have the units for a particular manufacturer, then can get the
name field from the ComponentDescription (or we may define a more unicode
friendly CFString version of this for AudioUnits) that can then describe to
the user what the effect actually is.
This does in effect give you 64 bits to specify your particular effect,
where you are however having to use 32 bits to specify your manufacturer ID.
Thanks
Bill
>
>
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/>
>
>
>
>
--
mailto:email@hidden
tel: +1 408 974 4056
__________________________________________________________________________
"...Been havin' some trouble lately in the sausage business," C.M.O.T.
Dibbler replied.
"What, having trouble making both ends meat?"
__________________________________________________________________________
_______________________________________________
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.