20 Apr
2006
20 Apr
'06
12:07 p.m.
Hiya,
I'm having a hard time finding the plugins I want when using Ardour,
particularly since the majority of plugins I have installed don't
provide categories via RDF.
So, hoping this is useful to others, attached is a minimal RDF for the
CAPS suite, which I use a lot.
This was generated by a quick python script, also attached; I just
hand-edited the output to change the plugin types from UnknownPlugin.
Wasn't sure what to do with the pan plugin.
I also haven't bothered to figure out what to do with all the stuff
about ports, and ardour doesn't seem to need it anyway, so this version
of the script doesn't handle that. (Hey Steve, what's all that port
info in your rdfs used for?)
--
Paul Winkler
http://www.slinkp.com
20 Apr
20 Apr
1:10 p.m.
On Thu, Apr 20, 2006 at 12:07:38 -0400, Paul Winkler wrote:
I also haven't bothered to figure out what to do
with all the stuff
about ports, and ardour doesn't seem to need it anyway, so this version
of the script doesn't handle that. (Hey Steve, what's all that port
info in your rdfs used for?)
Not much, in theory you can use it to make dropdown type boxes for
integer enumeration selectors, but I dont know if anyone does.
- Steve
1:29 p.m.
On Thu, Apr 20, 2006 at 06:10:35PM +0100, Steve Harris wrote:
On Thu, Apr 20, 2006 at 12:07:38 -0400, Paul Winkler
wrote:
Ah, I vaguely recall discussion of that now.
Too bad. Better auto-generated UIs for some plugins would be a wonderful
thing.
--
Paul Winkler
http://www.slinkp.com
I also haven't bothered to figure out what to
do with all the stuff
about ports, and ardour doesn't seem to need it anyway, so this version
of the script doesn't handle that. (Hey Steve, what's all that port
info in your rdfs used for?)
Not much, in theory you can use it to make dropdown type boxes for
integer enumeration selectors, but I dont know if anyone does. 
4:53 p.m.
[Paul Winkler]
On Thu, Apr 20, 2006 at 06:10:35PM +0100, Steve Harris
wrote:
The 0.3.0 CAPS release actually comes with an rdf file supposed to
label the enumerated int ports (the Cabinet model switches and the
SweepVF filter modes).
I haven't tried it myself but as it was provided by someone who's
using CAPS mainly in ardour I supposed it should work -- or does it
not?
Re: caps.rdf in general --
Paul, your permission assumed I'll recycle some of your python code,
to be run when making the CAPS 'dist' target. A better caps.rdf will
thus be in 0.3.1 (coming to a theatre near you sometime this year).
Steve, are the dc:creator, dc:rights, dc:title tags necessary? Paul's
caps.rdf simply copies the data found in caps.so -- is it possible to
simply eliminate this redundancy?
Cheers, Tim
On Thu, Apr 20, 2006 at 12:07:38 -0400, Paul
Winkler wrote:
Ah, I vaguely recall discussion of that now.
Too bad. Better auto-generated UIs for some plugins would be a wonderful
thing. I also haven't bothered to figure out what to
do with all the stuff
about ports, and ardour doesn't seem to need it anyway, so this version
of the script doesn't handle that. (Hey Steve, what's all that port
info in your rdfs used for?)
Not much, in theory you can use it to make dropdown type boxes for
integer enumeration selectors, but I dont know if anyone does.
6:28 p.m.
On Thu, Apr 20, 2006 at 10:51:20PM +0200, Tim Goetze wrote:
The 0.3.0 CAPS release actually comes with an rdf file
supposed to
label the enumerated int ports (the Cabinet model switches and the
SweepVF filter modes).
Argh! I already had 0.3.0, but apparently the gentoo ebuild fails to
install the rdf file. I'll file a gentoo bug.
I merged yours with mine and yep, it works - now I get both
categorization and useful dropdown widgets on those four plugins.
Yay!
btw, the guy that wrote yours didn't apparently understand
how the categories work. I had it mostly right by copying
other files, but I just now stumbled on where the taxonomy is
actually defined, it's at:
/usr/share/ladspa/rdf/ladspa.rdfs
... which apparently comes with liblrdf.
Re: caps.rdf in general --
Paul, your permission assumed I'll recycle some of your python code,
to be run when making the CAPS 'dist' target. A better caps.rdf will
thus be in 0.3.1 (coming to a theatre near you sometime this year).
Of course.
It should be possible to stub out the rdf for enumerated parameters by
looking at the "ports:" output of analyseplugin. That might be handy.
Steve, are the dc:creator, dc:rights, dc:title tags
necessary? Paul's
caps.rdf simply copies the data found in caps.so -- is it possible to
simply eliminate this redundancy?
dc (dublin core) metadata is generally optional.
I just put those in without thinking because it was easy to parse out.
I like having at least the title, it makes the rdf much more
human-readable.
--
Paul Winkler
http://www.slinkp.com
7:20 p.m.
[Paul Winkler]
True. But this should be valid xml/rdf too:
<!-- CabinetX: genuine tweed-covered, smoke-stained, whisky-drowned
'60s speaker cabinet, almost -->
Alas, humanely commented code has always been a rare commodity ... :))
Cheers, Tim
On Thu, Apr 20, 2006 at 10:51:20PM +0200, Tim Goetze
wrote:
rdf-install is a separate make target, that makes it easy to
overlook I guess.
The 0.3.0 CAPS release actually comes with an rdf
file supposed to
label the enumerated int ports (the Cabinet model switches and the
SweepVF filter modes).
Argh! I already had 0.3.0, but apparently the gentoo ebuild fails to
install the rdf file. I'll file a gentoo bug. I merged yours with mine and yep, it works - now I get
both
categorization and useful dropdown widgets on those four plugins.
Yay!
Good. The proposed 0.3.1 caps.rdf will more or less be the same merge.
btw, the guy that wrote yours didn't apparently
understand
how the categories work. I had it mostly right by copying
other files, but I just now stumbled on where the taxonomy is
actually defined, it's at:
/usr/share/ladspa/rdf/ladspa.rdfs
... which apparently comes with liblrdf.
Or here: http://plugin.org.uk/lrdf/examples/ladspa.rdfs
One thing I don't understand about this lrdf business is how you type
(or generate) a line that reads
<rdfs:Class rdf:about="http://ladspa.org/ontology#TimePlugin"
ladspa:hasLabel="Time">
when http://ladspa.org/ontology is (and has been for some time) a 404.
In any event, I'll make sure the plugin types are properly assigned.
It should be possible to stub out the rdf for
enumerated parameters by
looking at the "ports:" output of analyseplugin. That might be handy.
There's some old code I keep around that runs ladspa plugins under
python control (that's how the port info, cpu usage and
impulse/frequency response figures for caps.pdf are generated). It
comes with full python access to the port definitions, so it should be
rather easy to generate the rdf port info along with it.
Steve, are the
dc:creator, dc:rights, dc:title tags necessary? Paul's
caps.rdf simply copies the data found in caps.so -- is it possible to
simply eliminate this redundancy?
dc (dublin core) metadata is generally optional.
I just put those in without thinking because it was easy to parse out.
I like having at least the title, it makes the rdf much more
human-readable. 
8:13 p.m.
On Apr 20, 2006, at 7:17 PM, Tim Goetze wrote:
One thing I don't understand about this lrdf
business is how you type
(or generate) a line that reads
<rdfs:Class rdf:about="http://ladspa.org/ontology#TimePlugin"
ladspa:hasLabel="Time">
when http://ladspa.org/ontology is (and has been for some time) a 404.
The URI doesn't have to resolve. It's more a promise that it's a
unique name because presumably, you own the domain name.
Taybin
9:05 p.m.
On Thu, Apr 20, 2006 at 08:12:53PM -0400, Taybin Rutkin wrote:
On Apr 20, 2006, at 7:17 PM, Tim Goetze wrote:
Yep, that's something that took me a long time to accept about XML.
URIs are used as namespaces all over the place, and they very often
don't resolve to anything.
You get used to it eventually :-P
OTOH, it's pretty obvious why this is the case. Imagine if it *did* have
to resolve to something. What would that mean? it only works when the
server's up? (and DNS, and the end user's internet connection, and and
and...) That would suck so bad.
--
Paul Winkler
http://www.slinkp.com
One thing I don't understand about this lrdf
business is how you type
(or generate) a line that reads
<rdfs:Class rdf:about="http://ladspa.org/ontology#TimePlugin"
ladspa:hasLabel="Time">
when http://ladspa.org/ontology is (and has been for some time) a 404.
The URI doesn't have to resolve. It's more a promise that it's a
unique name because presumably, you own the domain name.
11:26 p.m.
On Apr 20, 2006, at 9:05 PM, Paul Winkler wrote:
OTOH, it's pretty obvious why this is the case.
Imagine if it *did*
have
to resolve to something. What would that mean? it only works when the
server's up? (and DNS, and the end user's internet connection, and and
and...) That would suck so bad.
I wonder why people include the protocol though? Using a java style
reverse DNS would have worked just fine:
org.ladspa.ontology would have made sense too.
Taybin
21 Apr
21 Apr
7:28 a.m.
On Thu, Apr 20, 2006 at 11:26:27 -0400, Taybin Rutkin wrote:
On Apr 20, 2006, at 9:05 PM, Paul Winkler wrote:
Heh, that's a whole long argument. In brief: I should have put a copy of
the ontology there (I meant to, just never got round to it), and that
means that if/when a human finds a ladspa rdf file in the wild, they can
type it in the namespace and find a copy of the ontology (with human
readable notes in it) that explains what it is.
If you use a tag: URI, or something else unresolvable then you dont have
the option to look it up, ever. But, if you use HTTP then you can put
something there, should you want to.
- Steve
OTOH, it's pretty obvious why this is the
case. Imagine if it *did*
have
to resolve to something. What would that mean? it only works when the
server's up? (and DNS, and the end user's internet connection, and and
and...) That would suck so bad.
I wonder why people include the protocol though? Using a java style
reverse DNS would have worked just fine:
org.ladspa.ontology would have made sense too.
22 Apr
22 Apr
5:31 a.m.
[Steve Harris]
On Thu, Apr 20, 2006 at 11:26:27 -0400, Taybin Rutkin
wrote:
Which naïve me was expecting to find. A LADSPA ontology ... I love
the idea.
I wonder why people include the protocol though?
Using a java style
reverse DNS would have worked just fine:
org.ladspa.ontology would have made sense too.
Heh, that's a whole long argument. In brief: I should have put a copy of
the ontology there (I meant to, just never got round to it), and that
means that if/when a human finds a ladspa rdf file in the wild, they can
type it in the namespace and find a copy of the ontology (with human
readable notes in it) that explains what it is. If you use a tag: URI, or something else unresolvable
then you dont have
the option to look it up, ever. But, if you use HTTP then you can put
something there, should you want to.
Please don't take it off your list of things to do.
Cheers, Tim
21 Apr
21 Apr
7:21 a.m.
On Thu, Apr 20, 2006 at 06:28:48 -0400, Paul Winkler wrote:
Parsing it out is a non-issue, its ignored unless you ask about it, and I
agree. I mostly included stuff like that becasue the way LADSPA embeds
data in the .so is wierd/wrong/underspecifed/anoying [delete as applicable].
- Steve
Steve, are the
dc:creator, dc:rights, dc:title tags necessary? Paul's
caps.rdf simply copies the data found in caps.so -- is it possible to
simply eliminate this redundancy?
dc (dublin core) metadata is generally optional.
I just put those in without thinking because it was easy to parse out.
I like having at least the title, it makes the rdf much more
human-readable.
20 Apr
20 Apr
1:21 p.m.
New subject: [linux-audio-dev] RDF for CMT, and slightly improved script
And here's some quick RDF for the CMT plugins, which greatly
reduces the number of "Unknown" plugins on my system.
Plus a slightly improved script (it takes the plugin filename as an
argument now).
For a couple of plugins I invented a "SynthesizerPlugin" and
"SurroundPlugin", which are (not surprisingly) not recognized by Ardour.
Is there a list somewhere of valid ladpsa RDF plugin types? I had a
look around the lrdf project page on sourceforge and didn't find
anything.
--
Paul Winkler
http://www.slinkp.com
21 Apr
21 Apr
7:39 a.m.
New subject: [linux-audio-dev] RDF for CMT, and slightly improved script
On Thu, Apr 20, 2006 at 01:21:12 -0400, Paul Winkler wrote:
And here's some quick RDF for the CMT plugins,
which greatly
reduces the number of "Unknown" plugins on my system.
Plus a slightly improved script (it takes the plugin filename as an
argument now).
For a couple of plugins I invented a "SynthesizerPlugin" and
"SurroundPlugin", which are (not surprisingly) not recognized by Ardour.
Is there a list somewhere of valid ladpsa RDF plugin types? I had a
look around the lrdf project page on sourceforge and didn't find
anything.
The list of default types is in the ontology file (ladspa.rdfs), but you can
just declare new ones in a file ships with the plugins, as in:
<rdfs:Class rdf:about="&ladspa;SurroundPlugin"
ladspa:hasLabel="Surround">
<rdfs:subClassOf rdf:resource="&ladspa;Plugin" />
</rdfs:Class>
eg. in swh-aux.rdf I declare SpectralPlugin and NotchPlugin, which I
needed, but aren't in ladspa.rdfs.
The nearest to Synthesiser is Generator, which is far from a good name.
The list of types was just hacked out by yours truely one afternoon, and
its both overspecified in some ways, and underspecified in others. It
could do with an overhaul.
- Steve
6892
days inactive
6894
days old
linux-audio-dev@lists.linuxaudio.org
13 comments
4 participants
participants (4)
-
Paul Winkler -
Steve Harris -
Taybin Rutkin -
Tim Goetze