Re: [LAD] Programming LV2 plugin from scratch tutorial video series

On 2021-10-20 14:26, David Robillard wrote: 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