Subject: [linux-audio-dev] Plugins and presets?
From: Frank Neumann (franky_AT_viona.de)
Date: Mon Dec 11 2000 - 14:07:11 EET
Hi,
I hope this topic hasn't already been discussed earlier; it's sometimes a
bit hard to follow the daily mail on LAD. :-)
Anyway, I was wondering if people have already thought about how to keep
preset data with plugins. Looking at VST plugins, I see e.g. a Reverb plugin
that comes with a list of "Small Room, Large Room, Chapel, Live Stage" and
more presets. Something similar should be possible in conjunction with
LADSPA, too, me thinks.
Here's just a quick list of things I believe would have to be discussed on
or implemented (please note I'm not offering to do this; I'm just doing wild
brainstorming here:-) :
- what data fields does a plugin want to store:
- one or several lines of text describing the name/purpose of a preset
(probably including the author, date, revision - this might sound like
overkill for simple filters, but looking at Steve's "Hermes" plugin,
it's maybe good to give credit to an author somewhere)
- parameters, put into some sort of a "name, type, value" list, like
"roomsize float 3000.0" for a 3000ms roomsize
- ...
- the user should be able to create/modify/delete presets. So the number of
entries can grow. Also, a way to import presets that other people have
designed might be necessary.
- where and under what name to store the data. As LADSPA gives each plugin
a unique ID, this could be part of the name. Maybe something like
~/.ladspa/presets/<plugin_id>.pre ? Or rather make <plugin_id> a directory
and put the presets under it, one per file?
- A utility library that unifies accesses to the preset data would be a good
thing to have. It should probably offer such functions as
ladspapreset_open() - gives opaque access to file name
ladspapreset_getinfo() - gets info, such as number of presets
ladspapreset_readpresets() - reads one/several preset/s, checks for validity
ladspapreset_writepresets() - you guess
ladspapreset_closepresets() - finished
...
This library could also be responsible for (read-)caching preset data.
- Of course, this also requires that all plugins have a way to offer their
presets to the user (GUI); this is where probably the XML stuff is called
for.
This writeup might not make very much sense in some points or contain serious
flaws; it's just a "flush of my brain" with hope for discussion. :-)
Frank
This archive was generated by hypermail 2b28 : Mon Dec 11 2000 - 14:53:32 EET