Re: AUBase preset handling change
Re: AUBase preset handling change
- Subject: Re: AUBase preset handling change
- From: h <email@hidden>
- Date: Wed, 18 May 2005 07:51:30 -0700 (PDT)
- Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
What is that clump name thing all about anyway?
I have searched but I cannot find any info on it.
--- Marc Poirier <email@hidden> wrote:
> On May 18, 2005, at 10:12 AM, Stefan Gretscher wrote:
>
> > Am 07.05.2005 um 12:23 schrieb Urs Heckmann:
> >> So, maybe it would be cool to add a Property like
> >> k_CanYouHandleSettingFrom that passes a ComponentDescription and
> >> returns noErr (Yep, I can) or k_SorryCannotHandleThisError (Nope).
> >>
> >> (Or even have a list of ComponentDescriptions for supported
> presets
> >> so that the host can know about it)
> > Isn't this exactly what kAudioUnitMigrateProperty_FromPlugin
> offers,
> > now that QT7 introduced kOtherPluginFormat_AU?
> > You can look at its documentation in the file OtherPluginsToAU.rtf,
>
> > where it's described for mapping from MAS and from VST.
> > Mapping from AU is even easier as the settings format is the same.
> >
> > kAudioUnitMigrateProperty_FromPlugin is a very useful property but
> it
> > seems hardly known by AU developers - there's only very few AUs
> that
> > have VST counterparts that support this. I'd like to take the
> > opportunity to promote this "forgotten feature" a bit, as it's
> fairly
> > easy to implement in an AU but very important for Logic users
> > importing songs from OS9 or Windows - and maybe in future also for
> > mapping between different flavours of AUs as Urs described.
>
> Yes, I agree, though also I think it's worth mentioning that the
> CoreAudio team could do something about promoting its use, namely
> adding convenient support for it in AUBase. One problem I've noted
> over the past year or so is that, every time a new property is added
> to
> the AU API, the SDK is not updated to account for them. And granted
> folks can do the handling themselves overriding GetPropertyInfo(),
> GetProperty(), and SetProperty(), but it would be nice if the
> CoreAudio
> folks kept up the SDK approach and made it easy for folks. Plus, I
> think that a lot of developers explore the options for AUs by looking
>
> at the virtual methods in the SDK classes, and there is no sign of
> any
> of the newer stuff if you do that (the one exception being the
> TransportState callback).
>
> The same thing could be said for support of clump names,
> value-to-string and string-to-value stuff, context name, etc...
>
> Marc
>
> _______________________________________________
> 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
>
Discover Yahoo!
Have fun online with music videos, cool games, IM and more. Check it out!
http://discover.yahoo.com/online.html
_______________________________________________
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