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