Re: What happened to factory presets?
Re: What happened to factory presets?
- Subject: Re: What happened to factory presets?
- From: Urs Heckmann <email@hidden>
- Date: Thu, 9 Jan 2003 01:20:10 +0100
Am Mittwoch, 08.01.03, um 20:35 Uhr (Europe/Berlin) schrieb Marc
Poirier:
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.
Sure. Sorry I always seem to confuse this :-)
SetAFactoryPresetAsCurrent is a non-virtual helper function for us AU
makers.
<snip>
is clear now. Should have searched the list more, I guess....
... have been late with presets (did the other stuff first), so I found
I'd just drop in when Robert came up with his question...
*** 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...)
2nd'd
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. ;)
Yupp, and I somehow like the idea of having a bunch of snapshots in
RAM, but it must be more flexible than VSTing...
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... :)
Hmm. I was thinking of a "preset morph time" parameter that blends the
current preset into the Program Change triggered
new preset. That would probably only work for AU based multiple user
preset management.
However, one could add, say 4, additional "slots" that could hold
different user presets and an x/y korgy joystick device control. Would
be interesting to make a saveState for this.
One could also argue for a whole mirror of the presets with an
"Edit/Compare" button like what came up with the infamous Romplers.
(Don't know why I sometimes feel familiar with this idea, maybe I
havn't found out that I don't)
However (I like this word!), the versatile ickzemmelly AU preset data
would allow for whole banks i.e. if you give them away in sense of "new
additional presets" for your customers. Might not be a too big
disadvantage if they couldn't assemble these themselves. Though if I
think of the KVRist community, I guess these guys would love to share
their stuff in banks rather than a bunch of single files.
However (again) arbitrary number of presets isn't built into AUBasics
(or I havn't found this, yet, being late with the Dec02Tools), it's
merely not restricted to stay at an initial amount. Which is good
compared to VST. Now we have to make something 17inch-like out of that.
Hope this was some helpful info and hasn't bored anyone to sleep...
;-)
Cheers,
;) Urs (who indeed needs sleep now)
urs heckmann
email@hidden
www.u-he.com
Why I create audio plugins instead of using them?
Here's the answer: www.u-he.com/music/
_______________________________________________
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.