Re: Filing of User Presets
Re: Filing of User Presets
- Subject: Re: Filing of User Presets
- From: Marc Poirier <email@hidden>
- Date: Thu, 24 Oct 2002 14:26:15 +0200 (CEST)
>
I am somewhat concerned about the need to support this but it seems
>
limited to synth AUs rather than effects.
What makes you say that?
>
However there is nothing stopping us putting presets inside
>
preset group entries in the Preferences dictionary: E.g.
>
Root - Dictionary
>
|- PresetGroups - Dictionary
>
| |- PresetGroupName - Array
>
| | |- PresetName - String
>
| | |- PresetName - String
>
| | .
>
| | .
>
|
>
|- Presets - Dictionary
>
| |- PresetName - Class info dictionary
>
| |- PresetName - Class info dictionary
>
|
>
|- UserDefault - String
>
>
This would allow us to write a browser interface that lets users select
>
from either a group or the entire list of presets.
People have been suggesting this sort of thing, and while it has some
seemingly nice advantages, I don't think it's a good idea to make a single
file of presets, or at least not to make it the only way. This is simply
not how musicians use preset files. Look around the internet and you will
find tons of web page hubs for plugin preset sharing, and that sort of
thing is much easier to do with individual files for each preset rather
than bunched files. For one thing, if the only way was to have a bunched
file, then when you downloaded one person's preset file for X plugin,
you'd have to trash yours (because you could only use one file). For
another thing, then Jenny Musician, whenever she has a new preset to
share for X plugin, has to delete her single file from the collection and
then reupload. Perhaps there could be the option for collection files,
but single files need to be possible, too.
>
This sounds good, but I would think that you might want to tag the data
>
a little more clearly? Something like: "vstdata"? There's already a
>
"data" entry in the class info for the AU preset info.
Yeah, I've been thinking about something like that, too, because
personally I do like to just keep the AUBase implementation of SaveState
and RestoreState and then work from there with my own data keys. The only
issue I think is that we need this to be defined by Apple, so it's not
just the way that Logic does it. But I agree with you 100%, having a
separate key for stored VST getChunk output would be ideal. Could someone
from Apple perhaps "bless" the key "vstdata" for these purposes? :)
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.