Re: Audio Unit - Saving/Loading custom data?
Re: Audio Unit - Saving/Loading custom data?
- Subject: Re: Audio Unit - Saving/Loading custom data?
- From: Brian Willoughby <email@hidden>
- Date: Sat, 23 Feb 2008 15:13:02 -0800
Yes, SaveState() and RestoreState() are the solution. For the most
part, nearly all parameters are stored in a dictionary, where
SaveState() and RestoreState() will automatically preserve their
values. But I believe that parameters cannot hold strings, so you're
probably forced to use properties. As far as I know, properties are
not automatically saved in the state dictionary.
It would seem that you have two choices:
(1) Implement SaveState() and RestoreState() in your AudioUnit
subclass to preserve your text notes, and don't forget to call the
superclass implementation so that all of your parameters are
preserved correctly. Even if you aren't using any parameters now,
you don't want to break that.
Advantage: Fully supported, AFAIK.
Disadvantage: When you add something new to GetProperty() and
SetProperty(), you must always remember to add it to SaveState() and
RestoreState()
(2) Modify GetProperty() and SetProperty() so that your text notes
are stored in the parameter dictionary. This latter option may not
be supported, and you would need to be careful to examine the
existing code to make sure you don't break anything. For example, I
don't think you'll be able to use the Indexed Parameters feature,
because your properties would muck that up. But this is not the
default mode anyway, unless there is a call to UseIndexedParameters()
early in your startup code somewhere. I believe that the parameter
dictionary can hold strings, even though the GetParameter() and
SetParameter() API only support 32-bit values.
Advantage: You only need to think about GetProperty() and SetProperty
(), because the default implementation of SaveState() and RestoreState
() will automatically handle anything you add to the dictionary.
Disadvantage: You're more likely to break something, and this
probably isn't exactly how things were intended to be used.
You might find option (2) more elegant because it is easier to
maintain. Then again, you might find it to be more of a hack to get
it working in the first place.
Good luck! At first, I thought you were in trouble, because I
thought you'd end up with channel one being e.g. "condenser mic" for
every song, i.e. the same notes would appear everywhere the plugin is
inserted, but I guess you've created a plugin that is a blank slate
by default, and only the notes that are entered and saved for a
particular song will show up. Seems like it should work after all.
Factory Presets would be almost useless with your plugin, I guess,
but song templates would be very useful, once created.
Brian Willoughby
Sound Consulting
On Feb 23, 2008, at 04:24, Drake Ironman wrote:
The idea is that the AU has a custom view with a TextView to allow
people to make notes on a track (mic setup etc). Now I need to
save/restore the serialized content of this TextView but I'm not
sure how to do it.
Obviously the GetPropertyInfo/GetProperty calls are used to pass
info between the custom view and the AUEffect; I can see how that
works easily enough. But how do I (within GetProperty) sore/
restore my binary content so that it gets stored (as with AU
parameter values) by the AH host.
Sounds like it should be simple and I get the impression that
SaveState might have a role to play.
Can anyone help?
Rich
_______________________________________________
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