Hi there!

I am in the process of adding preset management to my project FLAM
(custom GUIs for LADSPAs, flam.sf.net) which, by the way, is already
running under Rosegarden, checkout the SVN repo if you want to give it
a try.

For those interested I include below the specifications I have came up
with regarding preset management.

First I toyed with the idea of using SQLite to store the presets, but
there were some drawbacks to it (adding an extra dependency,
difficulties to manage list order, etc.) I was driven to it by the
wish of providing concurrent access from different instances of FLAM
but, in the end, I decided this feature was not worth the effort and
downgraded it to the possibility of reloading the preset list to get
the most up to date version at a certain point.

Then I gave a look at the preset API provided by lrdf but I don't like
it very much (makes use of uids -for retrieving the presets and for
avoiding triplet conflicts-, resulting file difficult to read by a
person.) OTOH it is somehow a standard (i.e., ardour uses it, any
other app?)

I have also thought of RDF/turtle as per the new LV2 spec but, if I am
not mistaken, raptor doesn't write turtle and, to be honest, all this
subject/predicate/object/ontology stuff seems like a bit of overkill
just to store groups of (int, float) pairs, although this may change
in LV2 if float is not the only type supported anymore.

Another thing I find awkward regarding preset management is that all
kind of ports share a common index space, so you have to pick the
input control ones among them. This makes the programmer resort to
convoluted data structures for what could be expressed, after all,
with just an array. Not really a big deal, but having the list of
input control ports singled out would make preset management easier.

I would be grateful for any advice on this subject.

Cheers,

Luis


---------------------------------------------------------------------
- Presets management interface:
---------------------------------------------------------------------

- Keyboard accelerators: Ctrl+[0-9] loads one of the first ten
presets in the list (1-based, Ctrl+0 loads item #10.) Ctrl+Shift+[0-9]
saves the current status of the plugin in the corresponding position
of the list (optional confirmation dialog.)
- Context menu: there is a Preset entry in the context menu with three
submenus: "preset manager," "load" and "save." "Load" and "save" unfold
a list of the available presets to load or save respectively. "Preset
manager" opens or brings to front the preset manager.
- Preset manager is a non-modal dialog that displays a list of the
available presets and the following buttons:
   - "Save list" dumps the preset list to the default disk location.
   - "Reload list" reloads the preset list from the default list
   location. Useful to share changes created in other instances of
   that FLAM.
   - "Export" exports the selected preset(s) to a user chosen file
   in a certain exchange format.
   - "Import" imports (adds) to the list the presets stored at user
   chosen file in a certain exchange format.
   - "Apply/Load/Retrieve/Set/Restore?" sets the plugin ports to the
   values stored in the preset (accelerator: doubleclick on the list.)
   - "Store/Save/Overwrite?" saves the status of the plugin to the
   selected preset (optional confirmation dialog.)
   - "New" creates a new preset from the current status of the plugin
   with a default name and enters immediately into rename mode.
   - "Delete" deletes the selected preset(s) from the list.
   - "Rename" changes the name of the preset (accelerator: click a
   selected item on the list.)
   - "Up" moves the selected preset one position up the list.
   - "Down" moves the selected preset one position down the list.

   Buttons "Save List", "Reload List", "New", "Import" are always
   enabled.
   Buttons "Apply", "Store", "Rename", "Up", Down" are enabled when
   only one item in the list is selected.
   Buttons "Export", "Delete" are enabled when one or more items in
   the list are selected.

Every plugin has two presets files (system and user) organized in a
tree following the DSSI recommendation.

Reply via email to