Re: Presets etc.
Re: Presets etc.
- Subject: Re: Presets etc.
- From: Marc Poirier <email@hidden>
- Date: Wed, 28 Apr 2004 20:22:17 -0400 (EDT)
On Wed, 28 Apr 2004, Michael Kleps [reFX] wrote:
>
>> thanks for clarifiying this. Unfortunatly I have to support VST and AU
>
>> and for simplicity I don't want to do any major changes to either
>
>> implementation. In fact, I have not modified a single line of code in
>
>> the VST version to make the AU version work. I will hence lie to the
>
>> host and tell him that I have no factory presets at all. Then the user
>
>> is forced to use my internal preset-management that is a LOT more
>
>> flexible (IMHO) then the AU one (presets can be changed and organized
>
>> in banks). VST handles presets like a RAM bank, so the user, not the
>
>> host, can decide what to do with it.
>
>
>
>
>
> ???
>
> Most users who I have dealt with prefer the AU approach to presets and
>
> find the VST "programs" concept to be confusing and lead to undesired
>
> behavior. But I really don't see how one case the user decides what
>
> happens and the other the host decides, that's a weird take on it...
>
>
Then you have different customers, but this could be from the different
>
platforms we work for. Most of my customers are PC users which use VST
>
and thus they are used to the VST behaviour.
I've done VST Windows stuff since many years ago, too...
>
I find the AU behaviour
>
very confusing and limiting. I have several AU beta-testers that
>
complained that their preset is always overwriting the first factory
>
preset
Buggy AU? That's certainly not what any AU should be doing, that's the
crummy behavior with VST.
>
and that when the load another soundbank (through the supplied
>
internal load functions) that the preset list in logic is not updated
>
to reflect this. Seems that even my Mac AU customers are used to the
>
VST behaviour.
Except that, as you've already learned, that's also not what any AU should
be doing. You don't load in new factory presets. A legitimate solution
has already been recommended: putting files in Library/Audio/Presets/etc.
>
Even hardware synthesizers have a RAM bank and not just
>
one slot. And when you do sysex dumps you always have the choice to
>
dump only the current preset or the entire bank.
Angus already gave a perfect response about the backwardsness of
immitating MIDI hardware with software, to which I won't add anything...
>
Anyway, I was lacking this information and was thus making false
>
assumptions. I will now lie to the host, provide my own load/save
>
functions (for presets AND banks, all in good old compatible FXP/FXB
>
format)
??? Compatible with what? Itself? It's VST-proprietary, as incompatible
as anything else can get.
>
and treat a "state" as a complete bank, so the user can use
>
program-changes to switch between several of HIS presets within one
>
bank. This is called "total recall" (saving *everything* related to the
>
plugin in the song) and this total recall functionality is NOT included
>
in AUl.
Yeah cuz it sucks (who needs their song document data bloated 128x or
however many "programs" there are in a given plugin's "bank" when they're
usually only using 1 and there are other fine methods of state
management available that aren't as backwards?) and cuz you provide banks
that are immediately accessible (thanks to the AU-standard location) which
can be modified using preset files in standard location. But instead
you'd rather knowingly not use a good solution and knowingly keep things
confusing by misimplementing the AU API, and then complaining about how
the AU API is confusing when it's misimplemented?
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.