Re: What happened to factory presets?
Re: What happened to factory presets?
- Subject: Re: What happened to factory presets?
- From: Marc Poirier <email@hidden>
- Date: Wed, 8 Jan 2003 20:35:58 +0100 (CET)
>
Hi Robert,
>
>
I also found that my AUs don't get calls to
>
>
SetAFactoryPresetAsCurrent (const AUPreset & inPreset)
>
>
but only for
>
>
NewFactoryPresetSet (const AUPreset & inNewFactoryPreset)
>
>
in my usual suspects, when a preset is selected.
The host has nothing to do with calling either of those, they are
completely internal to the AU (i.e. they are part of the SDK, not part of
the actual AU API). Remember, nothing outside of an AU actually calls any
of the AU methods (okay, except for callbacks when those connections are
made), everything is interfaced with properties, which AUBase mostly
handles for AU makers in the Dispatch* methods.
SetAFactoryPresetAsCurrent is a non-virtual helper function for us AU
makers. NewFactoryPresetSet is a virtual function that, if you are using
the AUPublic SDK (which we both are :), you need to implement if your AU
has factory presets. In *your* implementation, you can call
SetAFactoryPresetAsCurrent, which is an easy way to update the
mCurrentPreset member of AUBase. By default, AUBase will handle the
CurrentPreset property for you by calling NewFactoryPresetSet for you, but
if you have not overridden it with your own implementation, the default
(AUBase::) version simply returns an error.
*** note to Apple folks ***
Perhaps it should be made more explicit in the docs that the AUPublic SDK
is simply stuff that makes it easy for AU authors to create AUs correctly,
whereas the actual API is strictly contained in AudioUnit.framework and is
strictly limited to the Component Manager property system? This seems to
be a frequent point of confusion and comes up a lot. (Maybe I should
enter some of my ramblings on the topic to the CoreAudio swiki...)
>
Can anyone explain what's the difference between those?
>
>
Shouldn't it be this way:
>
>
Set..Current = User has chosen Preset from list
>
New... = Currently edited user preset overwrites a former factory
>
preset and replaces it for the current session
>
What about a flag for saveState that determines the user wants to save
>
the whole bank instead of only the current user preset?
You're thinking in VST terms here, Urs. ;) In AU, presets are actually
presets, unlike VST where they're this pseudo-hybrid of factory presets,
but also volatile "slots" for user state settings. But in AU, presets are
strictly read-only, non-volatile manufacturer state data. So no user
should ever want to save a bank of AU factory presets, because they're
already built into the plugin, and they can't be modified. As soon as one
is loaded and then modified, it enters the category of "user state", which
is what is saved and restored in ClassInfo stuff.
But in my opinion, I think it would be nice if the AU API added some
specification for a presets "bank" file format, but not having it anything
like the VST model for this stuff is a VERY GOOD DECISION, if you ask me.
;) Another benefit of the AU approach is that the bank file format
wouldn't be limited by the (rather arbitrary) "numPrograms" in VST. In AU
terms, that would mean that an AU preset bank file could only ever have
exactly as many presets in it as the AU has factory presets, no more or no
fewer. Which makes no sense because, given how AU handles this stuff,
there's no reason to use such a limitation and a preset bank format could
hold any number of presets in it. Presenting the presets in the bank (as
well as storing them) would be a duty for the host to handle, not the
plugin. Appending new presets to the bank file, deleting ones from the
file, etc., would all be host territory, the AUs themselves need not
manage this stuff. Uhhh, anyway, I was kind of just thinking about this
all yesterday (bank preset file format for AU), hence my further rambling.
I also wrote a long email to my current employer recently about the
differences between AU and VST preset systems, perhaps I should enter that
into the CoreAudio swiki too... :)
Hope this was some helpful info and hasn't bored anyone to sleep...
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.