search

free-audio / clap

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

Adds Preset Discovery #265

Closed abique closed 1 year ago

abique commented 1 year ago

The second matter was informing the host that a preset has been added, removed, or modified. Creating a temporary file for the host to watch and touching it when these things happen works. I wonder if there's a nicer API for this though, couldn't we just have a clap_host_preset_discovery_context or something like that with a callback and a method on the factory to set that context object? That would make rescanning based on triggers from the pluin a lot more robust and easier to implement in a cross platform way.

I clarify something:

  1. host must watch for each location recursively, so when you add a preset (using the file manager), the host should pick it up automatically using file system notification
  2. invalidation_watch_file is for invalidating the list of locations, file extensions, etc...

I don't think that the plugin can solve this for the indexer. Monitoring filesystem changes is not difficult and it is a requirement for any DAW, because the user may drop files at anytime using the file explorer (even samples).

Also there is no "plugin daemon / service" which is running all the time. And plugins aren't a single instance thing either.

defiantnerd commented 1 year ago

IMHO the strict focus on files annoys me a bit. Files come with all kind of implications that make such a library complicated (paths, user privileges, UTF8 characters). I am also not a big fan of "tags" like "Woodwind".. this is the kind of library stuff that didn't work for other hosts, too.

abique commented 1 year ago

IMHO the strict focus on files annoys me a bit. Files come with all kind of implications that make such a library complicated (paths, user privileges, UTF8 characters). I am also not a big fan of "tags" like "Woodwind".. this is the kind of library stuff that didn't work for other hosts, too.

What do you suggest then?

Regarding the indexing, it is not a problem to have a lot of information, the daw can always decide to show "less" or to organize the presets in a more minimal way.

baconpaul commented 1 year ago

I am also not a big fan of "tags" like "Woodwind".. this is the kind of library stuff that didn't work for other hosts, too.

What do you suggest then?

The easiest solution is to be silent on the keywords.

The second easiest is to be incomplete.

The hardest is to be relatively comprehensive

But the first and third are often better than the second. I wonder why we need to define any categories at all?

baconpaul commented 1 year ago

But if we are going to define categories, I would at least ask @mkruselj to think about some of his experience with genres, tags, and categories and give the list a once over :)

mkruselj commented 1 year ago

My suggestion would be to stay silent on the keywords, to be honest. Better don't define any if it's going to be sparse like this.

abique commented 1 year ago

This list isn't definitive, it can be extended. I don't see a point in not having it, the plugin can ignore it that's fine. The extension doesn't force the plugin to describe its content in a certain way, but it just gives the option to use a language which maybe will be understood by most.

abique commented 1 year ago

My suggestion would be to stay silent on the keywords, to be honest. Better don't define any if it's going to be sparse like this.

I've had a second thought at it and OK, I'll kill it.