Closed robbert-vdh closed 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?
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.
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:90s-hoover-bass.preset.zst
. Which should should be named90s-hoover-bass
or90s hoover bass
. Or a preset called Rhodes e-piano v1.2 final.json`, which has the name 'Rhodes e-piano v1.2 final'. Allowing explicit preset names would remove some potential host implementation errors that may not immediately be obvious until you run into a situation like this.