Re: AU Hosting and Persistence Questions
Re: AU Hosting and Persistence Questions
- Subject: Re: AU Hosting and Persistence Questions
- From: Marc Poirier <email@hidden>
- Date: Mon, 21 Oct 2002 15:35:40 +0200 (CEST)
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.