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

[hollundertee]

On Tue, 19 Oct 2021 11:38:57 +0200
Sven Jaehnichen  wrote:

> Am 19.10.21 um 00:13 schrieb Robin Gareus:
>
>  [...]
>
> This would be an interesting option :-). Although turtle has got a
> very intuitive syntax (once you know it), it might be a bit
> discouraging for newbies as it looks different than other data
> interchange formats like JSON or XML. Thus , the more familiar
> looking JSON-LD may help to overcome this obstacle.
>
> Best wishes
> Sven

Hey Sven,

thanks once more for your tutorial.
I followed it along so far, cleaned up the warnings lv2 reported and
made a stereo version of the plugin this morning.
The turtle stuff was the hardest bit.
Thankfully lv2lint reports what is wrong, if not how to fix it. For
that I had to search for the corresponding definitions or look at other
plugins. Ultimately it was a bunch of copy/pasting.
I do not think that would have been any different with a different
metadata language.

This was the easy part, now I am curious how you are going to attempt
to teach simple folk like me the art of DSP programming. :]

Best regards,
Philipp
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

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

[David Robillard]

On Wed, 2021-10-20 at 22:32 +0200, Fons Adriaensen wrote:
> On Wed, Oct 20, 2021 at 10:26:41AM -0400, David Robillard wrote:
>  
> > > 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.
> 
> No, it isn't. Sorry if I gave that impression. It's more likely what
> you refer to writing
> 
> > and the W3C and much of the semantic web community deserves a ton
> > of criticism

Fair enough, to be clear I just mean that in the context of LV2. 
Slightly more generally, also the context of most people/projects
actually using some of this tech in the real world.

The things you quite righly point out as silly pipe-dreams come from a
particular academic niche of quasi-logicians who are completely
divorced from real-world software development (and it shows).  Even
there, the argument that it's important to somehow describe the
universe is frankly pretty straw-manney (though I'm sure you can find
somebody in an armchair somewhere who thinks that), but regardless,
nobody really cares what that camp says at this point anyway.  Even in
the linked data world.

The more data-oriented people had good ideas that are useful in
practice and have literally nothing to do with semantics.  We need some
of that - mainly that whole extensibility thing.

I suspect that people imagine this is much more theoretical than it is.
This is how development of LV2 things happens in reality.  If you need
stuff, you can add stuff.  If people agree that the added stuff is
sane/useful, then perhaps it gets standardized.  There is no Steinberg
here to tell you what you're allowed to do.  This is why little ideas
like "IDs must be globally unique and can not clash" are so important.
It's why *you* get to invent them if you like, and you don't need
approval from me or anyone else to do so. 

Perhaps it's a bit messy, but that's how worse-is-better works.  I'll
take a working spec that's a bit messy over GMPI or whatever any day. 
/That/ tack is the pipe-dream, just a very different sort of one.

It's all very addressable, but as always, the real reason for things
still being pretty messy is as crass as it is simple: nobody's paying
anyone to make a really nice open source audio plugin specification. 
The freedom to pile in whatever you want, at the cost of things being a
bit chaotic and unpolished, is just the best we can do in these
circumstances.  At least it works.

-- 
dr
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

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

[Fons Adriaensen]

On Wed, Oct 20, 2021 at 10:26:41AM -0400, David Robillard wrote:
 
> > 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.

No, it isn't. Sorry if I gave that impression. It's more likely what
you refer to writing

> and the W3C and much of the semantic web community deserves a ton
> of criticism

Ciao,

-- 
FA


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

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

[Hermann Meyer]

Am 20.10.21 um 16:26 schrieb David Robillard:

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



For that case XUiDesigner may come handy, it will generate a complete
working LV2 bundle

from just stick a user interface per drag n' drop together.

You only need to insert your dsp code to make it a real world plugin.

https://github.com/brummer10/XUiDesigner
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

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

[Thomas Brand]

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  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

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

[David Robillard]

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 

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

[Fons Adriaensen]

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.

> 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. 

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.

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.

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.

Ciao,

-- 
FA

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

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

[Hanspeter Portner]

On 20.10.21 00:39, David Robillard wrote:

On Tue, 2021-10-19 at 22:51 +0100, Will Godfrey wrote:

On Tue, 19 Oct 2021 16:58:39 -0400
David Robillard  wrote:


On Tue, 2021-10-19 at 19:17 +0100, Will Godfrey wrote:



  What is even worse, is when there
is a problem of some sort with a plugin, and host reports that
the
(apparent)
url doesn't exist!


That's rather strange.  Most hosts don't even do internet access
whatsoever, and even if they did, I can't imagine why they'd be
trying
to fetch these ones.

Which host?


I must admit I can't find this now. I haven't checked for a long
time, so I'll
be the first to say I might have originally misinterpreted what I
saw.


Sounds like a bad error message to me.


This may have shown up in a bug report with output from *lv2lint*.
The latter can check for existence of license/homepage/plugin URLs.
But there's no need to freak out for the average paranoid, it's a
double opt-in: The feature *must* manually be enabled at compile-
time and *must* manually be enabled at runtime ;-)
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

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

[David Robillard]

On Tue, 2021-10-19 at 22:51 +0100, Will Godfrey wrote:
> On Tue, 19 Oct 2021 16:58:39 -0400
> David Robillard  wrote:
> 
> > On Tue, 2021-10-19 at 19:17 +0100, Will Godfrey wrote:
> 
> > >  What is even worse, is when there
> > > is a problem of some sort with a plugin, and host reports that
> > > the
> > > (apparent)
> > > url doesn't exist!  
> > 
> > That's rather strange.  Most hosts don't even do internet access
> > whatsoever, and even if they did, I can't imagine why they'd be
> > trying
> > to fetch these ones.
> > 
> > Which host?
> 
> I must admit I can't find this now. I haven't checked for a long
> time, so I'll
> be the first to say I might have originally misinterpreted what I
> saw.

Sounds like a bad error message to me.

Anyway, there is ongoing work to improve the tooling situation and
encourage (or better yet, force) their use on the developer side
*before* attempting to load into an arbitrary host.  I think that's the
solution here: guessing and seeing if it works in $ARBITRARY_HOST is
always going to be a really bad time, for many reasons (most of which
are much more confusing than this one).

Tools!  Tools!  Tools!

--
Deve Robbmer
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

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

[Will Godfrey]

On Tue, 19 Oct 2021 16:58:39 -0400
David Robillard  wrote:

>On Tue, 2021-10-19 at 19:17 +0100, Will Godfrey wrote:

>>  What is even worse, is when there
>> is a problem of some sort with a plugin, and host reports that the
>> (apparent)
>> url doesn't exist!  
>
>That's rather strange.  Most hosts don't even do internet access
>whatsoever, and even if they did, I can't imagine why they'd be trying
>to fetch these ones.
>
>Which host?

I must admit I can't find this now. I haven't checked for a long time, so I'll
be the first to say I might have originally misinterpreted what I saw.

-- 
Will J Godfrey
https://willgodfrey.bandcamp.com/
http://yoshimi.github.io
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [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 

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

[David Robillard]

On Tue, 2021-10-19 at 19:17 +0100, Will Godfrey wrote:
> On Tue, 19 Oct 2021 13:04:08 -0400
> David Robillard  wrote:
> 
> > On Tue, 2021-10-19 at 10:00 +0100, Chris Cannam wrote:
> > > And, of course, URIs are just strings - the fact that they are
> > > typically written with http at the start etc is just a namespacing
> > > convention. The lv2 standard could have used
> > >  instead of
> > >  and it would still work.  
> > 
> > I've honestly thought a few times that maybe using a custom scheme
> > would have been better.  It's objectively worse in every way, but the
> > instant people see "http" they lose their damned minds for some
> > reason
> > :)
> > 
> > C'est la vie...
> 
> I disagree.
> Like many people, if I see what looks like a valid url, then that's
> what I
> expect it to be, not some form of labelling.

In the case of all the LV2 specs, they are.

http://lv2plug.in/ns/lv2core#Plugin

>  What is even worse, is when there
> is a problem of some sort with a plugin, and host reports that the
> (apparent)
> url doesn't exist!

That's rather strange.  Most hosts don't even do internet access
whatsoever, and even if they did, I can't imagine why they'd be trying
to fetch these ones.

Which host?

-- 
dr
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

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

[Neil C Smith]

On Tue, 19 Oct 2021, 19:18 Will Godfrey, 
wrote:

> Like many people, if I see what looks like a valid url, then that's what I
> expect it to be, not some form of labelling.
>

It's common, eg. XML namespaces. More fun when people start complaining
they're not https. :-)

Best wishes,

Neil
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

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

[Fons Adriaensen]

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...

> 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 ?

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.

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.

Ciao,

-- 
FA



___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

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

[Will Godfrey]

On Tue, 19 Oct 2021 13:04:08 -0400
David Robillard  wrote:

>On Tue, 2021-10-19 at 10:00 +0100, Chris Cannam wrote:
>> And, of course, URIs are just strings - the fact that they are
>> typically written with http at the start etc is just a namespacing
>> convention. The lv2 standard could have used
>>  instead of
>>  and it would still work.  
>
>I've honestly thought a few times that maybe using a custom scheme
>would have been better.  It's objectively worse in every way, but the
>instant people see "http" they lose their damned minds for some reason
>:)
>
>C'est la vie...

I disagree.
Like many people, if I see what looks like a valid url, then that's what I
expect it to be, not some form of labelling. What is even worse, is when there
is a problem of some sort with a plugin, and host reports that the (apparent)
url doesn't exist!

Unless you know what this is you can waste a lot of time having been totally
misdirected. Speaking from experience :(

-- 
Will J Godfrey
https://willgodfrey.bandcamp.com/
http://yoshimi.github.io
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

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

[David Robillard]

On Tue, 2021-10-19 at 11:38 +0200, Sven Jaehnichen wrote:
> Am 19.10.21 um 00:13 schrieb Robin Gareus:
> 
> > There is currently ongoing work to allow JSON-LD as alternative,
> > but
> > that's just the encoding.
> 
> This would be an interesting option :-). Although turtle has got a
> very 
> intuitive syntax (once you know it), it might be a bit discouraging
> for 
> newbies as it looks different than other data interchange formats
> like 
> JSON or XML. Thus , the more familiar looking JSON-LD may help to 
> overcome this obstacle.

I am (somewhat idly) working towards this still, but it probably won't
make the upcoming round of major releases.  JSON-LD is much, much more
complicated to implement, specifically because it's *not* just a dumb
syntactic veneer for triples.

It does, however, not look weird, which is probably worth the effort,
even though it makes real the (currently imagined) problem of needing
access to vocabularies to parse anything at all.

-- 
dr
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

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

[David Robillard]

On Tue, 2021-10-19 at 10:00 +0100, Chris Cannam wrote:
> And, of course, URIs are just strings - the fact that they are
> typically written with http at the start etc is just a namespacing
> convention. The lv2 standard could have used
>  instead of
>  and it would still work.

I've honestly thought a few times that maybe using a custom scheme
would have been better.  It's objectively worse in every way, but the
instant people see "http" they lose their damned minds for some reason
:)

C'est la vie...

-- 
dr
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

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

[David Robillard]

On Tue, 2021-10-19 at 09:46 +0200, Fons Adriaensen wrote:
> On Tue, Oct 19, 2021 at 12:13:17AM +0200, Robin Gareus wrote:
> 
> > https://www.w3.org/TR/turtle/ to the rescue :)
> 
> Been there of course...
> 
> > Instead of e.g.   http://lv2plug.in/ns/lv2core#ControlPort
> > you can just write    lv2:ControlPort
> 
> That I understand. But:
> 
> 1. The logic that allows this is hard coded in the LV2 host,
>    it is not the result of 'including' the @prefix. Checking
>    that the @prefix is present does not mean that whatever
>    is hard coded corresponds to what the @prefix is supposed
>    to imply. This is what I mean when saying that all this
>    just provides 'an illusion of conformity'.
> 
> 2. If the intention is that people use the short form, why
>    bother with the long one at all ? The code that reads 
>    the ttl files can simply accept the short one without
>    even being aware of the equivalence to the long one.
>    Which then has no reason to exist at all. So to me
>    this looks like a solution in search for a problem.

It's just a namespacing mechanism for convenience.  Just as in C++
where you could write ::foo::bar::baz::quux::SomeClass everywhere, but
that would be extremely annoying, there is "using" to make it more
convenient.

That's all @prefix does in Turtle.  It has nothing to do with
semantics, or what properties/classes/etc "mean", or anything like
that.  It is an incredibly dumb mechanism that is (more or less) just
primitive string concatenation.

The reason you can't "just" use the short one everywhere is that they
are not globally unique (being the whole point).  It is just a
convenient document-local syntax, and the name of the prefix means
absolutely nothing (it is not present in the data whatsoever, @prefix
is analogous to a preprocessor directive).  In order to do that, we
would need to make a central authority that hands out blessed prefixes
for some purpose.  The reason URIs are used here is to not have to do
that, by just taking advantage of DNS (and people actually do use this,
a lot, both in general and in LV2.  Requiring permission to define
extensions is a total non-starter here).

That said, clearly there are too many prefixes, and it's annoying, but
this is a different issue.  JSON-LD(*) lets you write vocabularies
which contain more magic to avoid this, for example, but that actually
does introduce the issue you're suggesting here: you need that
vocabulary document to make sense of the document at all.  This is not
the case with Turtle.  You do not need the schema to parse the
document.  There doesn't even need to be a schema at all.  Ideally
there is, and often it is useful to take advantage of that (e.g. there
are comments and human-readable labels alongside machine-readable
information that can be used for validation and such), but as you say,
the "understanding" of some property or whatever can also just be built
in to the code.

In other words, your point 1 reads to me like "this mechanism doesn't
guarantee the document is semantically correct"?  Indeed, it doesn't. 
It doesn't have anything to do with that at all.  It's not pretending
to, either.  There is no illusion of conformity here, it's really just
a stupid token pasting mechanism and that's it.  Put another way,
Turtle is a syntax for describing data.  It is a syntactically valid
document to, say, set the label of a plugin to an integer.  It's not
semantically valid, but that's a wholly separate issue.

(* Which would probably be a good idea to adopt to make all this
perceived weirdness and bikeshedding go away.  Maybe some day..)

-- 
dr
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

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

[Sven Jaehnichen]

Am 19.10.21 um 00:13 schrieb Robin Gareus:


There is currently ongoing work to allow JSON-LD as alternative, but
that's just the encoding.


This would be an interesting option :-). Although turtle has got a very 
intuitive syntax (once you know it), it might be a bit discouraging for 
newbies as it looks different than other data interchange formats like 
JSON or XML. Thus , the more familiar looking JSON-LD may help to 
overcome this obstacle.


Best wishes
Sven
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

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

[Chris Cannam]

On Tue, 19 Oct 2021, at 10:00, Chris Cannam wrote:
> For example, I could have chosen to write [...]

naturally I notice a typo just after sending - forgot to capitalise the P of 
lv2:Plugin in my second version. Sorry. The capital initial in "type" URIs is 
also just a convention, btw.


Chris
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

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

[Chris Cannam]

On Mon, 18 Oct 2021, at 21:54, Fons Adriaensen wrote:
> Which raises the question why those @prefix lines are 
> required at all. [...]
> So all that these lines seem to provide is some illusion
> of conformity which isn't enforced or checked at all. 

I used to find this conceptually tricky as well. I think it's true that there 
is an illusion of conformance there. The @prefix lines have an official look to 
them that doesn't reflect the reality, which is simpler than it appears.

RDF itself is a structure of triples, in which each element (subject, 
predicate, object) can be a URI (a string with some limitations as to character 
content) or, in certain positions, other types such as literal character data. 
RDF doesn't have prefixes itself, they're a sort of macro expansion used in the 
Turtle format, which is intended to be written and read at least partially by 
humans.

On loading the Turtle document

@prefix lv2:  .
@prefix my:  .
my:plugin a lv2:Plugin .

what the RDF store actually receives is a single triple of three URIs, which in 
the more basic ntriples format would look like

 
 
 .

The two prefixed names are expanded, as well as the standard shorthand "a". But 
you didn't *have* to use the prefixes, you could have written exactly the line 
above (which is valid Turtle as well as ntriples). It's just that it's harder 
to write the document correctly that way. All that matters is that the second 
and third URIs (predicate and object) expand to exactly the strings shown, and 
that the first URI (the subject) is used consistently as the subject for all 
properties of your plugin.

So the above document is equivalent to any other Turtle document that expands 
to the same set of RDF triples. For example, I could have chosen to write

@prefix plu:  .
@prefix rdf:  .
 rdf:type plu:gin .

Run this through a Turtle-to-ntriples converter (e.g. rapper -i turtle) and 
you'll get the same output as before:

 
 
 .

And, of course, URIs are just strings - the fact that they are typically 
written with http at the start etc is just a namespacing convention. The lv2 
standard could have used  instead of 
 and it would still work.


Chris
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

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

[Hermann Meyer]

Am 19.10.21 um 09:46 schrieb Fons Adriaensen:

Instead of e.g.http://lv2plug.in/ns/lv2core#ControlPort
you can just writelv2:ControlPort

That I understand. But:

1. The logic that allows this is hard coded in the LV2 host,
it is not the result of 'including' the @prefix. Checking
that the @prefix is present does not mean that whatever
is hard coded corresponds to what the @prefix is supposed
to imply. This is what I mean when saying that all this
just provides 'an illusion of conformity'.



@prefix is just turtle language. It's nearly the first you read about in
the introduction for RDF 1.1 Turtle

https://www.w3.org/TR/turtle/#sec-intro

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

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

[Bruno Vernay]

Hi
I think that the intention was just to be able to use whatever short
name suits you.
You could use:
@prefix prj:  
@prefix l2:   
@prefix lv2:   

...

I am not judging.

Regards
Bruno
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

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

[Fons Adriaensen]

On Tue, Oct 19, 2021 at 12:13:17AM +0200, Robin Gareus wrote:

> https://www.w3.org/TR/turtle/ to the rescue :)

Been there of course...

> Instead of e.g.   http://lv2plug.in/ns/lv2core#ControlPort
> you can just writelv2:ControlPort

That I understand. But:

1. The logic that allows this is hard coded in the LV2 host,
   it is not the result of 'including' the @prefix. Checking
   that the @prefix is present does not mean that whatever
   is hard coded corresponds to what the @prefix is supposed
   to imply. This is what I mean when saying that all this
   just provides 'an illusion of conformity'.

2. If the intention is that people use the short form, why
   bother with the long one at all ? The code that reads 
   the ttl files can simply accept the short one without
   even being aware of the equivalence to the long one.
   Which then has no reason to exist at all. So to me
   this looks like a solution in search for a problem.


Ciao,

-- 
FA



___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

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

[Robin Gareus]

On 10/18/21 10:54 PM, Fons Adriaensen wrote:

> I never got to grips with turtle. 

https://www.w3.org/TR/turtle/ to the rescue :)

There is currently ongoing work to allow JSON-LD as alternative, but
that's just the encoding.

> In particular not with things like:

> @prefix doap:   .
> @prefix lv2:    .
> @prefix rdf:    .
> @prefix rdfs:   .
> @prefix 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).

URIs are just used as unique identifiers. They do not even need to
resolve and one can use urn: as well. However in most cases they point
to online documentation which is helpful to developers.

> Which raises the question why those @prefix lines are 
> required at all. 

@prefix just syntactic sugar, so you do not have to spell out the full
URI every time. Instead of e.g.
  http://lv2plug.in/ns/lv2core#ControlPort
you can just write
  lv2:ControlPort

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

Those URIs are defined in header files of the LV2 ontology and must
match, otherwise a LV2 plugin does not conform to the spec. There are
tools like lv2lint to check the validity, but other than that, they are
just unique IDs.

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

Except it is not ad-hoc, but a w3c standard. Why invent an new meta-data
schema for unique resource IDs, when there is already a very good one
out there, that is also formalized as RFC?

As side-effect you can also use existing tools from the semantic web to
index and search LV2 plugins. IIRC the MOD website uses that.

I hope that clarifies things,
robin




OpenPGP_signature
Description: OpenPGP digital signature
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

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

[Fons Adriaensen]

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:   .
@prefix lv2:    .
@prefix rdf:    .
@prefix rdfs:   .
@prefix 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
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

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

[_low_show]

Looks great, will make some time to try it out! Thanks for making this!


On Mon, 11 Oct 2021, at 12:00, linux-audio-dev-requ...@lists.linuxaudio.org 
wrote:
> Send Linux-audio-dev mailing list submissions to
> linux-audio-dev@lists.linuxaudio.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.linuxaudio.org/listinfo/linux-audio-dev
> or, via email, send a message with subject or body 'help' to
> linux-audio-dev-requ...@lists.linuxaudio.org
> 
> You can reach the person managing the list at
> linux-audio-dev-ow...@lists.linuxaudio.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Linux-audio-dev digest..."
> 
> 
> Today's Topics:
> 
>1. Programming LV2 plugin from scratch tutorial video series
>   (Sven Jaehnichen)
> 
> 
> --
> 
> Message: 1
> Date: Sun, 10 Oct 2021 13:58:57 +0200
> From: Sven Jaehnichen 
> To: linux-audio-annou...@lists.linuxaudio.org,
> linux-audio-dev@lists.linuxaudio.org, de...@lists.lv2plug.in
> Subject: [LAD] Programming LV2 plugin from scratch tutorial video
> series
> Message-ID: 
> Content-Type: text/plain; charset=utf-8; format=flowed
> 
> Hi,
> 
> I started with a programming tutorial series about making LV2 plugins. 
> Really from scratch. Dedicated for beginners.
> 
> I read in chats from so many hobbyist and bedroom producers that that 
> they want to make LV2 plugins but they don't have any idea how to start. 
> The most of them have got some basic programming experience. With Java, 
> Python, Javascript, or maybe some basic C/C++. I want to take them by my 
> hand and want to guide them to make some LV2 plugins. Step by step. I'm 
> also going to explain technical aspects. The turtle language, how LV2 
> plugins work, what is realtime, and so on.
> 
> The first videos are online:
> 
> https://youtu.be/51eHCA4oCEI
> 
> Two more are already pre-produced, and will follow within the next weeks.
> 
> In addition, there's a great resource by David called LV2 book 
> https://lv2plug.in/book/ which helped me to start just a few years ago.
> 
> Please give me some feedback. And I'm open for any suggestion.
> 
> Regards,
> Sven
> 
> 
> --
> 
> Subject: Digest Footer
> 
> ___
> Linux-audio-dev mailing list
> Linux-audio-dev@lists.linuxaudio.org
> https://lists.linuxaudio.org/listinfo/linux-audio-dev
> 
> 
> --
> 
> End of Linux-audio-dev Digest, Vol 176, Issue 2
> ***
> 
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

[LAD] Programming LV2 plugin from scratch tutorial video series

[Sven Jaehnichen]

Hi,

I started with a programming tutorial series about making LV2 plugins. 
Really from scratch. Dedicated for beginners.


I read in chats from so many hobbyist and bedroom producers that that 
they want to make LV2 plugins but they don't have any idea how to start. 
The most of them have got some basic programming experience. With Java, 
Python, Javascript, or maybe some basic C/C++. I want to take them by my 
hand and want to guide them to make some LV2 plugins. Step by step. I'm 
also going to explain technical aspects. The turtle language, how LV2 
plugins work, what is realtime, and so on.


The first videos are online:

https://youtu.be/51eHCA4oCEI

Two more are already pre-produced, and will follow within the next weeks.

In addition, there's a great resource by David called LV2 book 
https://lv2plug.in/book/ which helped me to start just a few years ago.


Please give me some feedback. And I'm open for any suggestion.

Regards,
Sven
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev