[LAD] Programming LV2 plugin from scratch tutorial video series

[David Robillard]

On Tue, 2021-10-19 at 21:12 +0200, Fons Adriaensen wrote:
> On Tue, Oct 19, 2021 at 01:00:24PM -0400, David Robillard wrote:
> 
> First of all, thanks to all who responded !
> 
> Hi David, long time no see...

'lo!

Indeed.  I'm trying to get back into cleaning up various messes, this
one included, but... life is hard.

> > The reason you can't "just" use the short one everywhere is that they
> > are not globally unique (being the whole point). 
> 
> But why should it be globally unique ? Is a 'my-pluign.ttl' supposed
> to have any meaning outside the context it is normally used in ?


They inherently have to be somehow?  If the key was just, say, "value",
then that could mean anything.  A spec/extension/whatever needs to
define what that means and how to use it, etc.

Anyone can define such a thing (and many do, including implementation-
private ones), so there needs to be a way to claim a namespace for your
extensions.

There isn't really a context of meaning here, some property, say
https://lv2plug.in/ns/lv2core#enabled just means what it means.  You
can use LV2-defined stuff wherever if you like, and LV2 stuff can use
elsewhere-defined stuff if it's handy.  Both of these are common things
to do.
 
> I can't help but having the impression (which may be completely
> wrong)
> that all these ontologies and the way they refer to each other are
> somehow supposed to create 'meaning' out of nothing. Which I think is
> an illusion - and a far more dangerous one than the one I referred to
> earlier.

Any system that defines anything does that.  That's what it means to
define things.

That said, there is a lot of bullshit surrounding LV2 and semantic web
technologies, and the actual world of ontologies and such out there is
a horrific mess.  The logic people have made an even worse mess on top
of it.  None of that really matters though, LV2 just uses the basic
idea of a triple-based data model and standard syntaxes for it.  I'll
be the first to recommend ignoring absolutely everything the W3C and
especially the OWL types say about any of this.

> Reading all the ontologies that relate to e.g. LV2, the only reason
> why I can understand and use them is because, being a audio engineer
> and a programmer, I know what a 'plugin', 'host', 'port', etc. are.
> Without that knowledge, there would be no meaning. And of course 
> one could add more and more and maybe even be able to somehow define
> 'plugin' while only referring to much more general concepts. But at
> the lowest level one would always have to refer to something that
> can understood just by itself.

Though a hilarious thing to say in this context: this just sounds like
semantics to me? :)

The only reason you can understand a C header that defines a struct
with filter coefficients or whatever is the same.  What's the
difference?

If there's an impression here that somehow there is a machine-readable
description of everything down to first principles that could be used
to construct an implementation or whatever, that is /not at all/ the
idea or intent.

LV2 is using this stuff just as a very flexible data format, which
allows anyone to define and use new things without stepping on anyone's
toes, allowing data to be easily
parsed/processed/transformed/loaded/etc by generic tools, and so on. 
This is mainly useful in practice for two reasons:

1) Developers can define new things if they want, and describe their
plugin better, if there is information that is useful for a host to
know.  This "definition" can simply be a comment that explains, in
plain english, what it means, and that's totally fine.  Usually there's
a bit of machine readable stuff in there as well to describe, say, what
data types are appropriate for the value or whatever, because this is
handy (and at the very least enables validation tools and such), but
generally we only define things that are useful.

2) The "mechanical" flexibility of the data itself is handy in many
ways.  For example, some hosts load a single plugin's data into their
own internal data structures, some host load a single plugin's data
into a general model in memory and work from that, and some hosts load
every single plugin/ontology/preset/whatever in the system into the
same big model and work from that.  All of these are fine, you can
literally cat files together, or do things that are conceptually
equivalent to doing that, and it doesn't matter.

So, concretely, mostly we're just using the idea of a data
representation that is simply a set of triples, with identifiers that
can't clash (because of the URI thing).  We use a bit of vocabulary for
describing classes/properties/etc where it's useful to have that
information in a machine-readable form, but that's because... well,
it's useful.  It's just the RDFey way of saying things like "the
plugin's label must be a string" or "a control can have only one
default value".

So, essentially you're right: LV2 does not describe plugins in a
machine-readable way all the way down to (some arbitrary set) of first
principles.  It's not trying to, that would obviously be a total wank.
It's describing audio plugins for audio developers and audio software.

Things only mean what we say they mean, based on some base set of
common understanding.  That would be true regardless of how it's
written down: RDF, JSON, C, C++, plain text, spoken conversation.  Here
we just tend towards machine-readable where it makes sense, because
machine-readable is more useful than not.  That's all.

-- 
dr