Re: Misc AU hosting questions
Re: Misc AU hosting questions
- Subject: Re: Misc AU hosting questions
- From: Marc Poirier <email@hidden>
- Date: Fri, 20 Feb 2004 17:11:25 -0500 (EST)
Robert, you're right, I forgot to mention that in the "behavior notes" for
SaveAUStateToPresetFile(), but that function does take care of doing that
for you. I should ammend my docs for that.
I really encourage host developers to use my library! It's not because of
any sort of self-promotion thing, and I don't care if you use it and never
tell me that you did. But it just does a good job taking care of all of
the AU preset file stuff and making that really easy for you and will
save you lots of time, and it does it in a way that gives a good user
experience, too. And it's free to use in any sort of project, the only
license restrictions apply to redistribution of the source code (and you
can't sue me if things don't work the way you wanted).
I wrote it because I was tired of so many hosts doing a sub-par and
inconsistent (or nonexistent) job handling all of this stuff, so I that's
mostly why I want folks to use it, to have music software be slightly
better. :)
Marc
On Fri, 20 Feb 2004, Robert Grant wrote:
>
Just a comment on saving AUPreset files - something that has been
>
forgotten (and in my brief scan of your page Marc I didn't spot it) in
>
at least one host:
>
>
It's my opinion that you should change the name of the preset in the
>
plist to the name that the user entered in the save dialog (minus
>
.aupreset of course). Thus when it is loaded back the displayed preset
>
name (in the host or AU) will show the name of the file - which is what
>
users expect.
>
>
Tthere was at least one host that wasn't doing this , making some of
>
the early Zebra presets very unfriendly as I loaded a cool sounding
>
preset and got something called "Initialize" or worse the name of a
>
different preset upon which this preset was based!
>
>
Just something to remember.
>
>
Robert.
>
>
>> If so, is there anything preventing the host to manage multiple
>
>> user presets? (i.e. the host will take care of getting/setting
>
>> the ClassInfo when a preset is changed so that for the AU
>
>> there will only be one user preset)
>
>
>
> I'm not sure what you mean when you refer to "when a preset is
>
> changed",
>
> but yeah, you can come up with any way you want to allow managing of
>
> custom user state presets. If you are talking about preset files,
>
> please
>
> read the info here:
>
> http://destroyfx.org/dfx-au-utilities.html#preset_files
_______________________________________________
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.