[LAD] Programming LV2 plugin from scratch tutorial video series

David Robillard d at drobilla.net
Wed Oct 20 16:26:41 CEST 2021


On Wed, 2021-10-20 at 10:10 +0200, Fons Adriaensen wrote:
> On Tue, Oct 19, 2021 at 05:32:59PM -0400, David Robillard wrote:
> 
> > life is hard.
> 
> And complex, having real and imaginary parts.
> 
> > The only reason you can understand a C header that defines a struct
> > with filter coefficients or whatever is the same.
> 
> True.
> 
> > What's the difference?
> 
> That C isn't trying to describe the entire world.

This is a glaring straw man.  I'm not sure what you're arguing against,
but it certainly isn't LV2.

> > 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.
> 
> Nor would it work (IMHO). But the impression is given that it would,
> in particular when discussing the alleged advantages. 

>From who?  Given how?

> When some new plugin feature is defined, then in the end some human
> programmer has to understand it using his/her domain-specific
> knowledge.
> And if that is the intent, things could be a bit simpler. Even the
> very
> restricted C vocabulary (and some common sense) would be enough.

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.

> A a programmer I like to avoid dependencies and keep things as simple
> as possible, which probably explains why my brain goes in self-
> defence
> mode whenever I try to get any closer to LV2... Please don't take
> that
> personally, I'm very well aware of how useful LV2 has been to the 
> Linux Audio world.

Fair enough.  "I just want to write C and only C" is a reasonable and
understandable position, no need for any hand-wavey nonsense.

As it happens, we could do that, without even really breaking anything
in a significant way, *specifically because everything is based on a
simple abstract data model*.  If someone makes a C API that can
describe the same information, then it could be used to access the data
instead.  This could be used to generate static data files where that
makes sense, or it could be used at runtime to dynamically discover
plugins, or both.  The same API could be used in either case.  I would
like to actually do this for various reasons, but it's not a high
priority.

This is the sort of thing you can easily do with a simple abstract data
model (a set of triples), and that's the sort of thing that LV2
actually takes advantage of.  What's going on here is really much more
of a Scheme-like idea than some semantic pipe dream.

So, concretely: we really could remove all of that Turtle stuff, and it
would not be a very deep change, loosely analogous to just writing a
different parser.  Everything past that in the implementation would
remain absolutely identical, not one character of code changed.  That's
not an accident, and this sort of thing is why people who *do* grok LV2
are not interested in throwing out all of the babies with the
bathwater.  The fact that we can change all of these superficialities
and still retain everything that we have built so far is also a big
reason why nobody cares that much.  Work on new features and new/better
ways of describing plugins/etc will be useful, even if LV2 evolves to
become something that does not look at all like the current LV2 at
first glance.  We all have our gripes with Turtle, and with the idea of
static metadata in separate files - but those can be addressed.

> I just can't help having the impression that most of the 'semantic
> web' stuff is just a load of hype. And that is something I try to
> keep my distance from.

As you should.  It's very telling that this conversation, and most of
the ones like it, are not actually about concrete technological issues.
They're about people finding terms like "RDF" and "semantic web",
googling them, falling down some rabbit hole or another, and ending up
at very bizarre conclusions like some syntax being used makes the whole
technology stupid and utopian (or whatever) because it's trying to
define the entire world or... something.  It's very understandable how
people end up at such nonsense, and the W3C and much of the semantic
web community deserves a ton of criticism for making that situation,
but it's nonsense all the same.

You'll certainly get no argument from me that that situation is a
nightmare.  I've been slowly expunging it from the documentation for
years now, gently pushing third-party documentation efforts to do the
same, and will continue to do so until absolutely none of it is left. 
Hopefully then we can spend more time talking about, and addressing,
real problems...

We can paint the shed whatever color we like, because the shed is built
on a foundation of good ideas.  The fact that some of those ideas are
loosely associated with bad ones is irrelevant (except in PR terms). 
That's true of all ideas anyway.

-- 
dr


More information about the Linux-audio-dev mailing list