On Sun, Jan 18, 2009 at 00:04, Luis Garrido < luisgarrido(a)users.sourceforge.net&gt; wrote: And I can do the frug

Just a small excerpt of discussions I remember reading or participating in, In chronological order: http://lalists.stanford.edu/lad/2002/05/0420.html http://lists.linuxaudio.org/pipermail/linux-audio-dev/2004-January/006293.h… http://lists.linuxaudio.org/pipermail/linux-audio-dev/2006-September/016810… I even entertained the idea of using sqlite and made some tests once, go figure. Everyone can advocate a format and there are compelling arguments for every single one of them. The difficulty lies in convincing other developers with different views and priorities to adopt yours. Good luck with that!

2009/1/18 Sebastian Moors &lt;mauser(a)smoors.de&gt;de>: Right For the format, let me suggest JSON. It's a plain text format. Supports utf-8. Parsers for different languages already exist. Properties can be nested. Human editing is simple. More info here: http://en.wikipedia.org/wiki/JSON http://www.json.org/ The path might depend: $HOME/audiofx-presets/preset_name/dssi/plugin_name/ $HOME/audiofx-presets/preset_name/lv2/plugin_name/ Main config file: $HOME/audiofx-presets/preset_name/main_config.json The main_config could suggest the host to load plugins of different types in this case... and the plugins could store data (wav files, etc.. ) in its subfolders ... We could setup a draft at: http://wiki.linuxaudio.org/wiki/audiofx_plugin_format_draft ..and gather suggestions for parameter names, options, and groups there. -- Emanuel

i like JSON too, except the lack of first-class URIs yo can map the key names to RDF predicate URIs trivially as well. personally i just use absolute URIs for the keys, since JSON has no namespace mechanism if you want JSON with a namespace mechanism and first class URIs, you might want to check out turtle, which tada, LV2 already uses. from your email i assume youre unaware of this? LV2 uses a bundle 'folder'. im not sure i think /usr/lib/lv/blahblah.lv2 is the right place for samples. /usr/share/lv2/blahblah.lv2 maybe at which point you have 2 'bundles'.. one bundle for each app-specific FHS location? that sounds wrong to me, and is the opposite of the idea of a bundle a FSHy subdir inside the bundle dir (inside /usr/lib) ? i hate that even more.. 404 i presume lv2 already has this stuff

To be utterly pragmatic, I think at this moment the best approach for this problem would be an evolutionary one. Just implement whatever format you feel like and see if it takes. No one is going to sue you, although you are guaranteed to get your fair share of critics, no matter what. At the worst case, this particular situation is so utterly simple that it should be trivial to convert one format to another if the need arises. If it helps in the end I chose for my project INI files just because it was a Qt app and Qt provides a nifty INI parser (QSettings) with some merging capabilities (concurrent Qt processes can make changes without corrupting the file and those are easily synchronized.) But that was me just being lazy, I guess. As for the directory structure it went something like: Global: /usr/share/ladspa/presets/plugin-name/preset-name.ini Local: ~/.ladspa/presets/plugin-name/preset-name.ini It is a ladspa-centric app, so it seemed appropriate. I don't recall now if ladspa's can be versioned, but it should be easy to insert a version number somewhere (in the path, in the ini file...)

Luis Garrido schrieb: In fact, being lazy can be good. INI files nearly use a YAML syntax which is also very easy to parse with C, C++, python and perl. -- Marc-Olivier Barre -- --- MarcO'Chapeau ---- - www.marcochapeau.org -

On Wed, 21 Jan 2009 15:20:24 +0000 (GMT), Sylvain HENRY &lt;hsyl20(a)yahoo.fr&gt; wrote: oh, thanks. I had been looking for this one :) -- Marc-Olivier Barre -- --- MarcO'Chapeau ---- - www.marcochapeau.org -

On Wed, 2009-01-21 at 23:07 +0200, Stefan Kost wrote: No, no, and a hundred times no. This is the code needed in ardour to load a named preset: --------------------------------------------------------------- bool Plugin::load_preset(const string preset_label) { lrdf_defaults* defs = lrdf_get_setting_values(presets[preset_label].c_str()); if (defs) { for (uint32_t i = 0; i < (uint32_t) defs->count; ++i) { // The defs->items[i].pid < defs->count check is to work around // a bug in liblrdf that saves invalid values into the presets file. if (((uint32_t) defs->items[i].pid < (uint32_t) defs->count) && parameter_is_input (defs->items[i].pid)) { set_parameter(defs->items[i].pid, defs->items[i].value); } } lrdf_free_setting_values(defs); } return true; } ---------------------------------------------------------------------- The ONLY reason that Ardour would ever switch to some other "format" is if there is similarly easy way of loading presets. This means a pre-existing "library" (at the very least, 2 function) to get the load/save done. This means, as I said a few days ago, that the core question is not what format to use, but where these functions are supposed to live. Right now, most linux distro's have liblrdf (the library ardour uses) as a package. What is the actual problem with this format (other than that its essentially illegible to regular humans) ? What problem is solved by using some other format/library. Note that, just for comparison, Apple AU's have their presets stored as XML. The contents are opaque to everything except the plugin (even though they are technically human-readable.

On Fri, 2009-01-23 at 20:45 +0200, Stefan Kost wrote: given a unique integral ID for a plugin: lrdf_uris* set_uris = lrdf_get_setting_uris(id); if (set_uris) { for (uint32_t i = 0; i < (uint32_t) set_uris->count; ++i) { if (char* label = lrdf_get_label(set_uris->items[i])) { labels.push_back(label); presets[label] = set_uris->items[i]; } } lrdf_free_uris(set_uris); } // GTK2FIX find an equivalent way to do this with a vector (needed by GUI apis) // labels.unique(); return labels;

Stefan Kost wrote: last time i looked, fons was distributing a global rdf file for all his plugins as a separate download. fons, is there any particular reason not to split it up and ship the appropriate parts with each of your ladspa packages?

On Mon, 2009-03-09 at 02:07 +0100, Fons Adriaensen wrote: That does not work very well with packages. If I have a package for each of the plugin collections (which I do), where do I put the rdf file? (I think I have it somewhere but I forget where...) -- Fernando

On Mon, 2009-03-09 at 03:46 +0100, Fons Adriaensen wrote: You can't do that. Or to be more precise, it is possible to have the exact same file in several packages but then it has to be the _exact_ same file and a change in _one_ package will break the upgrade process with a file conflict. There is no substitute to having a file that describes the plugins that belong to that package. Then they can all be upgraded separately, etc, etc, it is the way to go. Oh... well... changing package names is fun! (obsoleting and providing the old package name, etc, etc - but I think most of the plugins have actually migrated from Planet CCRMA to Fedora, so it is going to be somebody else's problem! :-) -- Fernando

On Mon, 2009-03-09 at 04:08 +0100, Jens M Andreasen wrote: Ha... There should be an rdf file in each tarball that describes the plugins that are part of that tarball. Anything else is a hack. There is no need (that I can see) for the rdf description to be a separate file that describes all plugins. -- Fernando

Stefan Kost schrieb: http://www.kokkinizita.net/linuxaudio/downloads/fa-plugins.rdf The direct link was wrong in an earlier mail in the archive :/ Stefan

Stefan Kost schrieb: Okay I found the other parts in the ardour sources. If I got it right from the few comments in lrdf.h, the presets are most likely stored in *.n3 files. Lrdf package actualy installs one with the dev package under /usr/share/doc/packages/liblrdf-devel/examples/preset-in.n3 here. Is is so that none of the ladspa plugins atualy ship any of those? Also in ardour I have not yet found a plugin that actualy has presets. Stefan

Paul Davis schrieb: Thanks for the confirmation. Its thats quite sad. It would be nice if people send their presets to the plugin authors and they merge them and ship them with future updates. Stefan

Paul Davis schrieb: One thing that we need to figure is how to handle them. Presets shipped with the plugins (regardless of ladspa or lv2) should go to $prefix/share/... (e.g. /usr/share/ladspa/presets). Idealy it would use the same basename as the so uses. Application need to be prepared to read presets from there, but store (and read) them in the users home directory. For merging I would suggest to read the system wide presets and then read the user-presets - in case of a double entry the user-preset wins. Ardour stores them under $HOME/.ladspa/ardour.n3, that could be a bit problematic if other apps want to use them too. Using separate n3 files for each plugin and ev. even require to use flock on them would help to avoid conflicts (yes I know the limits of flock, but is there anything better?). I would prefer if the location is in sync with the freedesktop user-dir spec also. Stefan