On 2021-10-20 14:26, David Robillard wrote:
The main reason LV2 uses separate data files is so that hosts don't need to load and execute code only to discover what plugins are present. This has pros and cons, like most things.
It has some merit to have all metadata in a text file separate from the binary plugin. The drawback is obviously that both need to be in-sync all the time. That however can be easily achieved by somehow automating the creation of metadata from the code (which otherwise a host would do from the binary). Whether or not the markup of text metadata is reasonable to be in turtle is mostly a style choice, it could have been XML or JSON, which have their own pros/cons, or st. else.
The beauty of a single file to contain everything also has some merit. Going from a scenario, where the set of available plugins on a given systen won't change hourly, a way to tackle this would be to leave the process of finding plugins and creating a metadata (~ repository) from queryable binary files a totally separate and even optional and temporally fully user-controlled process. A host could still use that (speced-out) central repository through 'universe' or similar, but should also be able to get the info directly from a given single-file plugin path.
Naively my imaginary plugin spec would eventually embed metadata as EBML at an offset to be queried by the host or the other way around, have a single EBML-encoded file with all metadata plus the binarie(s) inside. Eg. Matroska uses EBML for binary markup of video, also webp / webm is such dialect. Parsing seems very simple, it's a well-defined recursive form of <id><length><content> where id and length are encoded as variable size integer (first byte is giving info about following data, not unlike a MIDI event in some aspect). It won't solve any semantic issues though.
Without deep reasoning I mostly share Fons' views onto the surrounding topics. This of course includes also that LV2 has become a de facto standard with many 'compatible' plugins and hosts that work. This is totally separate from whining on tech / style choices :)
Greetings Thomas _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
