Re: AUBase preset handling change
Re: AUBase preset handling change
- Subject: Re: AUBase preset handling change
- From: Urs Heckmann <email@hidden>
- Date: Sat, 7 May 2005 12:23:13 +0200
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
Am 07.05.2005 um 03:11 schrieb William Stewart:
In the base classes we provide for implementing an Audio Unit, we
currently do a sanity check (AUBase::RestoreState) on the preset an AU
is given by checking that:
The Type, SubType and ManuID match the particular AU.
We'd like to propose a slight modification to this test - to avoid
checking that the AU type matches, but rather just check that the
subtype and manuID match.
We believe this is a good change because identical AU's can be
published as different AU types, and it seems rather silly to reject
what would otherwise be a totally appropriate and valid preset.
For example, we ship two versions of AUTimePitch in Tiger; an 'aufc'
(Format Converter) version (so it can be used in a real-time like
context), and an 'auol' (Offline version) - which is of course much
better to use in an offline processing situation. In both of these
cases, the processing and parameter structure of the AU is identical,
so the presets could be shared between these two AU's. The same
applies to the AUVarispeed.
In these two cases the constants are:
aufc, vari, appl
auol, vari, appl
aufc, tmpt, appl
auol, tmpt, appl
This would require of course that an AU that shares the same manuID
and subtype would be able to parse and read the presets - both of
these fields are defined by the manufacturer, so this is totally
within the control of the manufacturer to manage.
If there are no objections to this, we'd make this change available in
the next SDK we release (sometime after WWDC)
Thanks
Bill
_______________________________________________
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