More questions on preset discovery

[sagantech]

I like preset discovery and I believe the functionality found here should be mandatory for any plug-in standard. I have it semi-working but the documentation is not great. The most useful information can be found in preset-discovery,h:

 The API works as follow to index presets and presets metadata:
   1. clap_plugin_entry.get_factory(CLAP_PRESET_DISCOVERY_FACTORY_ID)
   2. clap_preset_discovery_factory_t.create(...)
   3. clap_preset_discovery_provider.init() (only necessary the first time, declarations
   can be cached)
        `-> clap_preset_discovery_indexer.declare_filetype()
        `-> clap_preset_discovery_indexer.declare_location()
        `-> clap_preset_discovery_indexer.declare_soundpack() (optional)
        `-> clap_preset_discovery_indexer.set_invalidation_watch_file() (optional)
   4. crawl the given locations and monitor file system changes
        `-> clap_preset_discovery_indexer.get_metadata() for each presets files

Deciphering what responsibilities are assigned to the host is a bit challenging. The word 'crawl' is not defined so either the plug-in or the host must look through the file system looking for preset files. Since I only have one plug-in that supports preset-discovery it is hard to tell if I, as the host, or it, as the plugin is doing the wrong thing. I call clap_preset_discovery_indexer.get_metadata() for the built-in presets (something like this):

                                                for (int i = 0; i < numLocations; ++i)
                                                {
                                                    ....
                                                    cpdp->get_metadata(cpdp, locations[i].uri, &MCMetadataReceiver);
                                                }

when i == 0, I get called back for each preset but when i == 1 and the location points to a "\File" directory, get_metadata calls on_error and no presets are returned. Is the host support to traverse the file system to find presets in certain cases?

[robbert-vdh]

If the URI is a file path that points to a directory (or a symlink to a directory) then the host should crawl it for presets, yes. If the plugin declared file types then it filters the results by those file types, and then calls get_metadata() with URIs pointing to all matched files.

[sagantech]

Thank you Robbert-vdh for the clarification on get-metadata.

I think there also needs to be a clarification on the definition of a URI. For example I would presume that the output from this function "https://learn.microsoft.com/en-us/windows/win32/api/shlwapi/nf-shlwapi-urlcreatefrompatha" would be an acceptable URI input. My understanding is that the space character is not a safe URI (or URL) character and needs to be escaped with %20. If that is the case then the example from preset-load.h:

// - "file:///home/abique/.u-he/Diva/Presets/Diva/HS Bass Nine.h2p", load_key: null

is incorrect.

[robbert-vdh]

They technically indeed aren't URIs. I do think not having to do percent-encoding on URIs in CLAP is a good thing though since there's no reason for it. It's needed in text-based protocols since spaces are used as delimiters, but in CLAP every string is a standalone UTF-8 encoded string. Right now a plugin or host only needs to check and strip the protocol prefix from the 'URI'. Adding percent encoding would add mandatory ceremony and more surface for making mistakes to both sides without any benefits. I guess before the extension is stabilized it would need to be decided whether to use actual RFC 3986 URIs, or to explicitly mention that these URIs aren't actual URIs as much as they are protocol-prefixed paths.

[sagantech]

Using the name 'URI' is a mistake then.

[sagantech]

They technically indeed aren't URIs. I do think not having to do percent-encoding on URIs in CLAP is a good thing though since there's no reason for it."

I totally agree. In fact there is no reason to use the uri prefix either. You could simply pass a flag that says whether the system path is a path or it is built-in presets. Then there would be no path conversion necessary at all.