Re: AUBase preset handling change
Re: AUBase preset handling change
- Subject: Re: AUBase preset handling change
- From: Marc Poirier <email@hidden>
- Date: Sat, 7 May 2005 08:38:32 -0400
I don't see any reason why that would need to be a property. I think
that all that is in order in that case is for the AU to override
RestoreState() with its own implementation that checks for either of
those allowable values rather than only one. I think that what Bill is
talking about here is just what is the most appropriate default
behavior, and what Bill proposes sounds good to me, personally.
So far as building in better support in AUBase for what you're talking
about, again, I see a new property as an overblown and unnecessary
solution, but I think that dividing RestoreState() into its stages and
making them all virtual methods would make sense. e.g.
AUBase::RestoreState() might simply call
RestoreState_CheckStateVersion(), RestoreState_CheckComponentInfo(),
RestoreState_RestoreParameterValues(),
RestoreState_RestorePresetName(), etc. And all of those would be
virtual, so you could just override RestoreState_CheckComponentInfo()
in your AU if you wanted to allow more subtypes to be compatible.
This will also be good for those unfortunately braindead-designed AUs
that have separate versions for mono and stereo (ugh) and stuff like
that.
Marc
On May 7, 2005, at 6:23 AM, Urs Heckmann wrote:
Hiya,
I would even go a bit further. Imagine the case when a manufacturer
offers two versions of a plugin, like SuperFurbler Express and
SuperFurbler Pro, both of which have same Type/manuID and different
SubType. The Express version would naturally be a subset of the Pro
version. But the Pro version might be able to handle an Express preset
without problems.
In another example, a developer might license one of his plugin in an
OEM deal, to the effect that there are two plugins with identical
features but manuID and SubType might both differ. Nevertheless,
they'd be fully preset compatible.
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)
Oh, yes, if the Property is not supported, everything would work as
you predict ;-)
What do you think?
Cheers,
;) Urs
_______________________________________________
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