Re: AU Hosting and Persistence Questions
Re: AU Hosting and Persistence Questions
- Subject: Re: AU Hosting and Persistence Questions
- From: Bill Stewart <email@hidden>
- Date: Wed, 23 Oct 2002 12:56:30 -0700
I guess I should comment on this... (and correct me if I'm wrong:)
Marc is quite correct about our intentions with this...
We have a growing body of code that is RELYING on the fields that are
already used by the AU's class info, so if you are doing anything with the
class info data you must support the existing keys or you'll have problems -
I guarantee that!
As for the Factory Preset and class info... I think its a mistake to
associate a factory preset with saved state of an AU.
OK - I set the AU to a preset. Then I tweak one of the parameters - the AU
does NOT update its knowledge that it is no longer in a preset pure state.
Then you save it - then you restore it, thinking that your state was a
preset, but it isn't, its been modified. That is why we thought the best
course of action is to make the assumption that:
(1) ANY saved state is a user-preset state (ie. We don't save the factory
preset setting - but we save the current state of the AU)
(2) When a unit has its class info set, it is now in a user preset state...
And, as Marc said - in 90% of cases, you shouldn't need to touch this, it
will do the right thing for you
Bill
on 21/10/02 6:35 AM, Marc Poirier wrote:
>
Well, even though I'm not positive that I understand all of this correctly
>
(so please don't take all of this as guaranteed Truth(tm), and please
>
correct me if you know I'm wrong), but I'd like to try answering, at least
>
to test how well I understand this... :)
>
>
> The simple way is to store the parameter values. As this does not
>
> include the factory preset number and does not allow the AU to store
>
> any arbitrary data, I do this:
>
>
>
> First, I check if a CurrentPreset is selected.
>
>
>
> If so, I store the index of the factory preset. Should I also store
>
> each parameter value in this case?
>
>
>
> If CurrentPreset is -1, I ask for the ClassInfo and store that. Though
>
> it does not seem to be intended to store parameter values in this case,
>
> it seems to be needed for some of the current AUs.
>
>
>
> What is the recommended way to store a ClassInfo into a data block? Are
>
> the keys fixed or may an AU define additional keys? If the entries are
>
> limited to name, version, type, subtype, manufacturer and data, I can
>
> store each value and the AUs state is stored in the 'data' CFDataRef.
>
> But as ClassInfo is a property list and not a structure, I assume that
>
> an AU may define more keys. Should I then use
>
> CFPropertyListCreateXMLData()?
>
>
You, as a host author, do not need to worry about the data format of the
>
ClassInfo. That is handled by the AU itself. You simply tell the AU when
>
you want to get the data and when you want to give it old data back for
>
restoration of a previous state. You can also tell the AU, if it has
>
presets, when you would like it to set its state to that of a factory
>
preset. The AU is expected to store its data in a CFDictionary whatever
>
thingy with certain expected keys (data, manufacturer name, type, subtype,
>
version, name, and maybe something else that I'm forgetting). But you
>
don't need to worry about that yourself. And when you set the ClassInfo
>
property to restore an AU's state, the AU is responsible for taking that
>
data and restoring its state, you don't need to make the SetParameter
>
calls or anything like that.
>
>
One thing that you are responsible for, however, is managing when to set
>
the current preset to -1. Well, this is kind of a wavy area, because the
>
default RestoreState (from SetProperty(ClassInfo)) behaviour of AUBase is
>
to set the current preset to -1 at the end. This, I think, is also stated
>
in the header, that an AU is expected to be in -1 preset mode (user
>
preset) after a set call to ClassInfo. But in other situations, you (the
>
host) are responsible. Basically you can tell an AU to load a factory
>
preset and then it's current preset number will be >=0, but if any
>
parameter changes after that, the host is responsible for setting the AU
>
preset number to -1 (and can, for convenience, associate a new preset name
>
with that user state).
>
>
Marc
>
_______________________________________________
>
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.
--
mailto:email@hidden
tel: +1 408 974 4056
__________________________________________________________________________
"Much human ingenuity has gone into finding the ultimate Before.
The current state of knowledge can be summarized thus:
In the beginning, there was nothing, which exploded" - Terry Pratchett
__________________________________________________________________________
_______________________________________________
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.