Re: Filing of User Presets
Re: Filing of User Presets
- Subject: Re: Filing of User Presets
- From: "James Chandler Jr." <email@hidden>
- Date: Wed, 23 Oct 2002 14:12:40 -0400
>
I would vote for a subfolder called: Presets and then a subfolder
>
called AU or something
>
in order to differentiate AU presets from VST presets etc. (I was
>
thinking about putting
>
it under Plug-Ins but then it wouldn't mirror the hierarchy properly).
Hi Robert
I apologize for being ignorant of AU's, and have little time to study up on
them until after the Christmas rush. About any preset location that wiser
heads decide, would be fine as long as its standard (GRIN).
>
The question then becomes - what goes in the Presets folder. If it's
>
just a bunch of
>
.plist files then the user will have to provide an organization scheme
>
under Presets
>
or else give each file a *really* descriptive name. Fortunately given
>
the info in the
>
class data we can check to make sure a preset goes with an AU before
>
inflicting it
>
on the AU :-) I'm not sure how excited I am about building a preset menu
>
from a directory full of .plist files. It would mean loading all the
>
.plist files grokking their
>
class info and adding the right ones. If the user puts them in
>
subfolders then it would
>
make it even more unpleasant. This is why I was leaning to a preset
>
library file. Of course
>
Music Devices can have a *ton* of presets so even still some kind of
>
arbitrary subgrouping would be needed.
DirectX plugins are identified with unique GUIDs. To store an arbitrary
number of presets for any particular plugin, you just create or add to a
registry key named with the plugin's GUID, and then add sizeof(presetdata)
binary dumps to the plugin's key for each preset. Each binary preset data
block is named with the preset name.
So its pretty easy and simple to locate a plugin's key in the registry
(match off the plugin GUID), and then pull all the preset names under each
plugin's key into a drop-down menu or listbox. The problem is that different
software companies put their entire tree of preset keys at different roots
in the registry (GRIN).
Does OSX have built-in "easy" file key indexing capabilities that can be
cajoled to behave similar to the Windows registry? If so, perhaps something
along those lines could be used to maintain a big central "registry file" of
plugin presets?
>
As far as storing a chain of effects I think I remember Bill saying
>
that saving the state
>
of a graph (and thus being able to restore it) is in the plan but no
>
date yet. Of course
>
it would be the entire graph, not a fragment (such as the master effect
>
chain - we really
>
need those embeddable subgraphs :-) Would be a nice way to handle send
>
effects too
>
- if we had a mixer ;-)
Do you think all the "big companies" will use Apple-standard graphs?
Just wondering, because on Winders some major sequencer players write their
own graph managers which presumably run faster than MicroSoft filter graphs.
Are Apple Graphs pretty easy for a non-genius to parse?
James Chandler Jr.
_______________________________________________
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.