Is there a preset browser in Ardour?

Hi! I am not an advanced user of Ardour even though I am using it to compose music. Recently I have found that there is an option to save the plugin state, give it a name, and there is a list formed out of this. Thus, someone can create a kind of presets out of plugin states. Is there a way to store more data about the “preset” , author, category, other data? Is there a browser that can show this category hierarchy? Something like the preset browser from Zyn-Fusion synth ( https://user-images.githubusercontent.com/1049442/58372532-85be8180-7f40-11e9-9ee5-e687bc9da532.gif ) . If there isn’t and if you think it would be nice to be, I am open to try to develop it because this feature interests me when I am composing.

2 Likes

Ardour6 will have a basic preset-selector for plugins that have no controls and only presets. A list is displayed instead of a plugin-ui.

While LV2 could provide author, category and other custom meta-data, Ardour uses a least common denominator of VST, AU, LV1, LV2,… to represent presets. Hence the preset browser will be minimal and only show preset name and optional description.

Zyn’s preset browser is very specific to zyn-fusion.

I could try to develop small things if someone shows us how to do it. Maybe some video about developers how they work and what tools they use

It not an issue of implementation, but rather specifications. All common plugin-standards feature a flat namespace for presets. There is no specification nor convention how to define preset-categories, not even an established naming schema for preset-labels themselves.

If I understand @iuire.n correctly, he’d like a categorized tree-view. e.g.

Drums > Synth > [list of all presets that generate synthesized drum sound
Drums > Made By John > [list of all drum presets made by John]

with the possibility of presets being part in multiple categories, and preferably even sorted, perhaps even with an optional tag filter.

So the main issue is to define a way how to store and interpret that meta-data, and do so efficiently. Taking zyn-fusion’s example: reading ≥ 1000 complete state-files to parse meta-data only is likely no a good idea.

Then get plugin-authors to agree on using that defined spec for factory-presets that are shipped with plugins.

I expect that in the vast majority of cases it’ll only be factory presets that have proper meta-data, and the established way in this case is for the plugin to provide an appropriate preset-browser, tailored to the plugin’s needs.

Yes, I meant a tree view, also a way to save into this tree by adding all necessary info about the preset. It should not depend of the plugin format. As for metadata stored in the states by the plugin format I don’t know if they are really helpful for this case. As you said, here will be needed a database (maybe based on SQLight or something else) to be able to make different queries for the view (searching, sorting, tags) otherwise, I agree, it will be a slow process to gather this data from the states.

Interesting. Why do you think so?

In LV2s case, there’s rdfs:comment readily available. It is what Ardour shows as description in the preset browser.

Not a bad idea. I actually didn’t think of a relational database. But wouldn’t that be rather Ardour specific?

I was thinking to perhaps use rdfs:seeAlso. In LV2’s case the information could be part of the manifest. The main advantage would be that it’s always in sync with the actual preset (changing, deleting, re-creating presets), and also that factory presets can include a description and categorization.

An even simpler variant would be to simply tokenize the preset-name.
e.g. Vendor/Bank - Type/Category - Preset Name
I’ll try a quick prototype

I thought that maybe different formats of plugins may not provide the same functionality to store the necessary metadata in the states in order later to be able to recreate a tree out of this. But if you want to use tokens in names, maybe this can be stored for all plugin formats somewhere.

On the other hand every time the browser is opened for a specific plugin recreating the tree by “querying” the states tokens from the file system may take time. Also, I don’t know if loading these trees models in memory at startup will not take too much memory and also time for the startup if there are a lot of plugins and their presets. Some calculation can be made.

For example, changing a preset group would mean changing this token for all presets on the file system. Maybe it is not a big problem, but less efficient than a relational DB like sqlight. I didn’t know about $HOME/.lv2/. Since this kind of file system database may/already exists and is host portable, than adding a relational database specific to Ardour like sqlight (even only in memory) it will only improve presenting metadata, but not writing or changing because there will be need to keep in sync $HOME/.lv2/ with what is in DB. Thus, your proposal is optimal probably.

So far I’m mainly concerned with factory presets (think zyn or similar). Opted to at most 3 levels.

just using " - " separated preset-names and rdfs:comment in the LV2 plugins-preset. In case of LV2, presets are just bundles, so even factory-presets can be shipped separately.

Working prototype in ardour/git (6.0-pre0-2587-gc0866f54f3 or later) and an example plugin:

Feedback and suggestions are welcome.
It’ll still be a while until Ardour-6.0.0 until then the format can be changed easily. Perhaps colons should also be allowed “foo: bar: baz” or some heuristic that auto-detects the separator char/string.

I like it. Maybe in the preset column to strip out the S4 and Plates from the preset name since are shown already in Bank/Type columns. The factory presets that are not categorized maybe to be put into Factory/Factory. I don’t know if from factory the host can get info about kind of categories. Also, plugin authors probably will need to provide them in the factory presets.

Yeah, but I think that should only be done when a filter is active. When you list “all types” that information is still useful. – The layout also needs to be change. Too much space is currently wasted for “description”.

I’m glad that you like it. makes me think we’re on the right track, even if there’s still a long way to go.

Now the big question: do we need a separate tool to “organize and annotate” LV2 presets? Ardour can probably provide some basic “edit description, re-name/tag user-preset” functionality.

I think the same dialog but with an option to write the preset name and description, depending of the mode the dialog is opened, similar to a file browser dialog with a save/open mode.

The category and bank will be selected from the Bank/Category, or you can create/delete/rename them. This complicates things… but.

This will be tricky - in particular if bank/category is part of the preset name.
Factory presets are usually read-only (in /usr/lib/lv2) and cannot be renamed.

If the goal is to allow renaming those tags, a different approach will be required.

Do you mean tricky because there will be needed to rename all the presets metadata/names that contain that tag?

I think the factory presets to be placed into read-only banks of the preset browser. Thus, the user can’t modify nor the tags, nor the names.

Yes.

It’s an inconvenient side-effect of using re-names for this.

Ok, renaming for now can be avoided. I think creation should be easy, it is created when a first preset is saved.