[LAD] Programming LV2 plugin from scratch tutorial video series

Fons Adriaensen fons at linuxaudio.org
Mon Oct 18 22:54:57 CEST 2021


Sorry to _low_show - this was meant for the list.

On Mon, Oct 11, 2021 at 03:19:45PM +0200, _low_show wrote:

> Looks great, will make some time to try it out! Thanks for making this!
 
I somehow deleted the original post, but refer to

> https://youtu.be/51eHCA4oCEI
> https://lv2plug.in/book

I never got to grips with turtle. In particular not with
things like:

@prefix doap:  <http://usefulinc.com/ns/doap#> .
@prefix lv2:   <http://lv2plug.in/ns/lv2core#> .
@prefix rdf:   <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs:  <http://www.w3.org/2000/01/rdf-schema#> .
@prefix units: <http://lv2plug.in/ns/extensions/units#> .

All docs and tutorials I found mention that the URLs do NOT
mean that an application reading a file that contains them
would actually need to read them from the web (which would
be a unacceptable security risk anyway).

But that means that whatever is defined by those URLs
must actually be hard-coded in any LV2 host that reads
the 'manifest.ttl' or 'my-plugin.ttl' files.

Which raises the question why those @prefix lines are 
required at all. They could be used in theory to check
that what is hard-coded corresponds to what is defined
in those URLs. But to do that the application would 
need to access them.

So all that these lines seem to provide is some illusion
of conformity which isn't enforced or checked at all. 

So the conclusion is that this isn't any better than any
ad-hoc way of encoding the plugin metadata.

Or am I missing something essential ?

TIA for any reply that would enlighten me...

-- 
FA


More information about the Linux-audio-dev mailing list