Re: Filing of User Presets - files vs. builtin
Re: Filing of User Presets - files vs. builtin
- Subject: Re: Filing of User Presets - files vs. builtin
- From: "James Chandler Jr." <email@hidden>
- Date: Fri, 25 Oct 2002 13:24:34 -0400
Option 3 seems good to me.
>
> Cons: Host writers have to worry about creating the directory
>
> hierarchies correctly,
>
> possibly mitigated by some common code? Seems a little untidy?
>
>
This doesn't seem untidy to me. Also, perhaps I'm
>
overly optimistic, but I don't think creating the
>
directory hierarchies correctly would be an issue
>
for the vast majority of hosts. Of course, common
>
code would be good in helping to avoid (significantly
>
lessen?) the possibility of problems. I much prefer
>
this to Option 3 below ...
I apologize for wasting too much bandwidth, being awfully ignorant of OSX
implementation details.
Old Classic-style MoreFiles directory/file enumeration was some of my least
favorite drudgery programming. Lots of line of code with complicated
aggravating file-filter callback functions, just to create trees of folders,
or enumerate all the files of a particular type or content in a particular
folder.
Unless OSX functions exist to make this kind of task an order of magnitude
simpler, it sounds like simply building an application's hierarchical preset
pop-menu from many individual preset files and directories, would be an
aggravating thing to program.
Just from lightly reading Apples CFPreferences docs-- CFPreferences
functions look very simple to use, and quite similar to Windows Registry
read/write functions, which I've found to be easy for storing/retrieving
organized trees of stuff like small preset files.
>
> Option 3.
>
> <snip>
>
> Cons: Getting at individual presets is more difficult thus making
>
> sharing presets
>
> less straight-forward. Would mean implementing an import/export
>
scheme
>
> for
>
> individual presets. Concerns about scalability.
>
>
I don't like this option because of the problems
>
accessing individual presets (described by Marc in
>
another post). As well, the user loses the chance to
>
organize their presets. This could be an issue when
>
dealing with a large number of presets.
FWIW, here is a simple trick that is cunning enough to perhaps be worth
stealing to use in host applications (GRIN).
Cakewalk uses a simple and effective way to organize its Plugin hiearchical
menu by manufacturer. Apparently if it notices several plugins with a common
first word in the plugin name, it bunches all such in a hiearchical menu
item...
Since (by fortunate accident) many DX plugins have the company name as the
first word in the Plugin Name, in practice this simple sort works near 100%
to put plugins in proper hiearchical menus sorted by manufacturer.
If an application used similar simple logic to put presets in hiearchical
menu order, users (I think) could get easily accustomed to naming their
presets to influence preset ordering any way the user desires. All the
presets could be stored willy-nilly in a CPreferences file, and the
application could quickly sort them into proper hiearchical order for menu
display.
Ferinstance, the user could name some presets--
Guitar Spring Reverb
Guitar Stadium
Guitar Small Room
All such preset names would automatically appear under the Guitar
hiearchical menu item, regardless of their ordering in the CPreferences
file.
If you wanted to offer a more specific naming cue, could specify a
'standard' character for a parsing terminator, perhaps a simple '-' char.
Guitar- Spring Reverb
Guitar- Stadium
etc.
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.