free-audio / clap

Audio Plugin API
https://cleveraudio.org/
MIT License
1.73k stars 98 forks source link

Explicit preset names are not allowed for non-container presets #298

Closed robbert-vdh closed 1 year ago

robbert-vdh commented 1 year ago

According to this:

https://github.com/free-audio/clap/blob/065d685d4e9657f0344f350eef748be2b4d8e318/include/clap/factory/draft/preset-discovery.h#L114-L115

Non-container presets are now allowed to have a name. Was this intentional, or is this supposed to only refer to load_key? There are a couple prolbems with assuming the preset name corresponds to the file name that could be resolved by allowing or mandating explicit names:

abique commented 1 year ago

Yeah true. If we are on a file based preset system, it is convenient to see the filename in the list.

Imagine you have a presest a.preset named b and another file b.preset named b. What do you display?

robbert-vdh commented 1 year ago

They'll both be called 'b'. Having the preset name at least be optional for non-container presets allows for much more flexibility. There are lots of possible preset names that aren't valid file names, in which case the file name may be replaced, truncated, or substituted for something else entirely (imagine a plugin having PRESET1.dat, PRESET2.dat, ...PRESET99.dat files). And again, what name does the host display if the preset's filename is 90s-hoover-bass.preset.zst? Does it know .zst is a common extension used for files compressed using Zstandard, and whill it strip both the .preset and .zst and show 90s-hoover-bass? Or does it always strip everything after the first dot? If so, will the host (say, Bitwig) always display my sick reese v2.3.json preset as sick reese v2? I think at least allowing explicit preset names removes more ambiguity than it adds.