7 Jun
2008
7 Jun
'08
11:32 p.m.
Hello,
First of all I want to announce that the next version of NASPRO will
shift to LV2 as its internal model, which means that it will contain a
collection of bridges from other APIs to LV2 and viceversa
In order to accomplish such a thing (writing wrappers for LV2), a
special extension is needed to make the host call some function in a
shared object file to generate a new manifest.ttl-like file (possibly
using tmpfile() or similar). The host will call this function and read
the file to know about bridged plugins.
Now, I wrote something (taking "inspiration" from other extensions,
etc.), but since I'm a total beginner with RDF and LV2, please someone
check whether the following stuff is correct.
lv2_dyn_manifest.ttl:
@prefix : <http://naspro.atheme.org/ext/dyn-manifest#> .
@prefix lv2: <http://lv2plug.in/ns/lv2core#> .
@prefix dman: <http://naspro.atheme.org/ext/dyn-manifest#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix doap: <http://usefulinc.com/ns/doap#> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
<http://naspro.atheme.org/ext/dyn-manifest#> a lv2:Specification ;
doap:license <http://usefulinc.com/doap/licenses/bsd> ;
doap:name "LV2 Dynamic Manifest" ;
rdfs:comment "" ;
doap:mainainer [
a foaf:Person ;
foaf:name "Stefano D'Angelo" ;
foaf:homepage <http://zanga.netsons.org/>
] .
:DynManifest a rdfs:Class ;
rdfs:label "Dynamic Manifest" ;
rdfs:comment """
The class which represents a dynamic generator of a manifest.ttl-like file.
""" .
lv2_dyn_manifest.h:
#ifndef LV2_DYN_MANIFEST_H_INCLUDED
#define LV2_DYN_MANIFEST_H_INCLUDED
#include <stdio.h>
/* This function shall create a temporary file containing the dynamically
* generated manifest.ttl-like file and return a FILE pointer or NULL in case
* of failure.
*
* The generated file must not implement DynManifest classes. */
FILE * lv2_dyn_manifest();
#endif /* LV2_DYN_MANIFEST_H_INCLUDED */
I hope this is enough since I'm guessing that manifest.ttl can also
contain plugin-related information (the LV2 wiki suggests using
separate files, but maybe it's possible/valid nonetheless).
Then, some kind of API property could be associated to a plugin class
to indicate the original plugin API (needs an extensions or
something?).
In the end, I'm using FILE * because of file locking + standard C
library. If anyone is against that, please say so (with motivations).
Thanks in advance,
Stefano
8 Jun
8 Jun
8:20 a.m.
On 8 Jun 2008, at 02:31, Stefano D'Angelo wrote:
/* This function shall create a temporary file
containing the
dynamically
* generated manifest.ttl-like file and return a FILE pointer or NULL
in case
* of failure.
*
* The generated file must not implement DynManifest classes. */
FILE * lv2_dyn_manifest();
Seems like a solid proposal. I'm not familiar enough with the
extension mechanism to know if you need some extra stuff to define the
extension URI and so, but the idea seems solid.
One comment, it will be difficult for the plugin to know when it can
clean up the file. Obviously on UNIXy systems you can unlink it after
returning the FILE * to the host, and let the filesystem garbage
collect it later, but I don't think you can do that on Windows.
Maybe it would be a good idea to provide a lv2_dyn_manifest_done()
function or similar, so that windows-based plugins can clean up their
temporary files?
- Steve
9:51 a.m.
2008/6/8 Steve Harris <steve(a)plugin.org.uk>uk>:
On 8 Jun 2008, at 02:31, Stefano D'Angelo wrote:
Agreed.
Anyway I forgot to mention a couple of things:
1. A DynManifest is not a Plugin; Plugins and DynManifests can be
found inside the same bundle's manifest.ttl file (which is maybe kind
of lame?)
2. I don't really understand how does the :binary property exactly
works. I see the LV2 spec does not define it, but it is referenced
inside manifest.ttl files as lv2:binary. Is that some kind of property
belonging to some base class or...? And what if it is not present?
3. The binary property in the generated file should probably refer to
the same binary .so file containing lv2_dyn_manifest* (opening other
APIs' plugins should be done in lv2_dyn_manifest* itself IMO to avoid
inconsistencies).
4. What about multiple DynManifests in the bundle's manifest.ttl file?
In case they refer to the same binary, should lv2_dyn_manifest_*()
functions be called in the original order for lv2_dyn_manifest() and
reverse order for lv2_dyn_manifest_done() (static data would do some
trick in this case; this simplifies my own work somehow - modular
wrapper - but maybe it's not that beautfiul)?
Ideas?
Stefano
/* This function shall create a temporary file containing the dynamically
* generated manifest.ttl-like file and return a FILE pointer or NULL in
case
* of failure.
*
* The generated file must not implement DynManifest classes. */
FILE * lv2_dyn_manifest();
Seems like a solid proposal. I'm not familiar enough with the extension
mechanism to know if you need some extra stuff to define the extension URI
and so, but the idea seems solid.
One comment, it will be difficult for the plugin to know when it can clean
up the file. Obviously on UNIXy systems you can unlink it after returning
the FILE * to the host, and let the filesystem garbage collect it later, but
I don't think you can do that on Windows.
Maybe it would be a good idea to provide a lv2_dyn_manifest_done() function
or similar, so that windows-based plugins can clean up their temporary
files?
9 Jun
9 Jun
5:32 a.m.
On 8 Jun 2008, at 12:51, Stefano D'Angelo wrote:
2008/6/8 Steve Harris <steve(a)plugin.org.uk>uk>:
Nope, there's no reason to say where the declaration appears, you can
link in more RDF files with rdfs:seeAlso if you with to, which is
somewhat like #include.
On 8 Jun 2008, at 02:31, Stefano D'Angelo
wrote:
Agreed.
Anyway I forgot to mention a couple of things:
1. A DynManifest is not a Plugin; Plugins and DynManifests can be
found inside the same bundle's manifest.ttl file (which is maybe kind
of lame?)
/* This function shall create a temporary file containing the
dynamically
* generated manifest.ttl-like file and return a FILE pointer or
NULL in
case
* of failure.
*
* The generated file must not implement DynManifest classes. */
FILE * lv2_dyn_manifest();
Seems like a solid proposal. I'm not familiar enough with the
extension
mechanism to know if you need some extra stuff to define the
extension URI
and so, but the idea seems solid.
One comment, it will be difficult for the plugin to know when it
can clean
up the file. Obviously on UNIXy systems you can unlink it after
returning
the FILE * to the host, and let the filesystem garbage collect it
later, but
I don't think you can do that on Windows.
Maybe it would be a good idea to provide a lv2_dyn_manifest_done()
function
or similar, so that windows-based plugins can clean up their
temporary
files? 2. I don't really understand how does the :binary
property exactly
works. I see the LV2 spec does not define it, but it is referenced
inside manifest.ttl files as lv2:binary. Is that some kind of property
belonging to some base class or...? And what if it is not present?
It has to be present, otherwise there's no plugin.
3. The binary property in the generated file should
probably refer to
the same binary .so file containing lv2_dyn_manifest* (opening other
APIs' plugins should be done in lv2_dyn_manifest* itself IMO to avoid
inconsistencies).
The binary that contains the lv2_dyn_manifest* stuff should be the
same one as contains the run() IMHO.
4. What about multiple DynManifests in the
bundle's manifest.ttl file?
In case they refer to the same binary, should lv2_dyn_manifest_*()
functions be called in the original order for lv2_dyn_manifest() and
reverse order for lv2_dyn_manifest_done() (static data would do some
trick in this case; this simplifies my own work somehow - modular
wrapper - but maybe it's not that beautfiul)?
Can you think of a reason to have more than one? If not I'd say just
say that there has to be one. It's simpler. BTW, you get no implicit
ordering in RDF (it's a graph language), so if you want to order
things you have to number them in some way.
- Steve
5:57 a.m.
2008/6/9, Steve Harris <steve(a)plugin.org.uk>uk>:
Uhm, lv2.ttl doesn't seem to say anything about that.
Ok.
Ok, only one DynManifest.
If noone has any arguments against this extension, I'll "officially"
release it in a couple of days (with the adjustments outlined in this
thread, of course).
Stefano
On 8 Jun 2008, at 12:51, Stefano D'Angelo wrote:
Ok.
2008/6/8 Steve Harris
<steve(a)plugin.org.uk>uk>:
Nope, there's no reason to say where the declaration appears, you can
link in more RDF files with rdfs:seeAlso if you with to, which is
somewhat like #include. On 8 Jun 2008, at 02:31, Stefano D'Angelo
wrote:
Agreed.
Anyway I forgot to mention a couple of things:
1. A DynManifest is not a Plugin; Plugins and DynManifests can be
found inside the same bundle's manifest.ttl file (which is maybe kind
of lame?)
/* This function shall create a temporary file containing the
dynamically
* generated manifest.ttl-like file and return a FILE pointer or
NULL in
case
* of failure.
*
* The generated file must not implement DynManifest classes. */
FILE * lv2_dyn_manifest();
Seems like a solid proposal. I'm not familiar enough with the
extension
mechanism to know if you need some extra stuff to define the
extension URI
and so, but the idea seems solid.
One comment, it will be difficult for the plugin to know when it
can clean
up the file. Obviously on UNIXy systems you can unlink it after
returning
the FILE * to the host, and let the filesystem garbage collect it
later, but
I don't think you can do that on Windows.
Maybe it would be a good idea to provide a lv2_dyn_manifest_done()
function
or similar, so that windows-based plugins can clean up their
temporary
files? 2. I don't
really understand how does the :binary property exactly
works. I see the LV2 spec does not define it, but it is referenced
inside manifest.ttl files as lv2:binary. Is that some kind of property
belonging to some base class or...? And what if it is not present?
It has to be present, otherwise there's no plugin. 3. The binary
property in the generated file should probably refer to
the same binary .so file containing lv2_dyn_manifest* (opening other
APIs' plugins should be done in lv2_dyn_manifest* itself IMO to avoid
inconsistencies).
The binary that contains the lv2_dyn_manifest* stuff should be the
same one as contains the run() IMHO. 4. What about
multiple DynManifests in the bundle's manifest.ttl file?
In case they refer to the same binary, should lv2_dyn_manifest_*()
functions be called in the original order for lv2_dyn_manifest() and
reverse order for lv2_dyn_manifest_done() (static data would do some
trick in this case; this simplifies my own work somehow - modular
wrapper - but maybe it's not that beautfiul)?
Can you think of a reason to have more than one? If not I'd say just
say that there has to be one. It's simpler. BTW, you get no implicit
ordering in RDF (it's a graph language), so if you want to order
things you have to number them in some way.
7:11 a.m.
On 9 Jun 2008, at 08:57, Stefano D'Angelo wrote:
Uhm, lv2.ttl doesn't seem to say anything about that.
You're right, we never defined the lv2:binary predicate.
That should be fixed.
- Steve
2. I don't really understand how does the :binary
property exactly
works. I see the LV2 spec does not define it, but it is referenced
inside manifest.ttl files as lv2:binary. Is that some kind of
property
belonging to some base class or...? And what if it is not present?
It has to be present, otherwise there's no plugin. 
8:23 p.m.
New subject: More proposed LV2 addition/extension stuff
Steve Harris wrote:
You're right, we never defined the lv2:binary
predicate.
While you're adding stuff to lv2core, you might as well consider adding
some of those (+/- any discussions that arise and probably rewrite in
proper English), or perhaps I should move some of them into separate
extension(s):
:trigger a :PortProperty ;
rdfs:label "Trigger" ;
rdfs:comment """
Indicates that the data item should be considered a Boolean value
corresponding to the specific event that was detected (control output
ports) or is to be triggered (control input ports). For input ports, the
port needs to be reset to false by the host (any value less or equal
than 0) after run() function is called.
""" .
(Boolean? discrete? based on if :integer or :toggle is present? a
feature that says :trigger that is supported? use special labeled events
instead?)
:supportsStrictBounds a :Feature
rdfs:label "Supports strict bounds" ;
rdfs:comment """
Indicates use of host support for :hasStrictBounds port property. A
plugin that specifies it as optional feature can omit value clamping for
:hasStrictBounds ports, if the feature is supported by the host. When
specified as required feature, it indicates that the plugin does not do
any clamping for input ports that have a :hasStrictBounds property.
""" .
:hasStrictBounds a :PortProperty ;
rdfs:label "Has strict bounds" ;
rdfs:comment """
For hosts supporting the :supportsStrictBounds, it indicates that the
value of the port should never exceed port's minimum and maximum control
points. For input ports, it moves the responsibility for limiting the
range of values to host, if it supports :supportsStrictBounds. For
output ports, it indicates that values within specified range are to be
expected, and breaking that should be considered by the host as error in
plugin implementation.
""" .
These probably belong somewhere else, but I'll post them anyway:
:expensive a :PortProperty ;
rdfs:label "Changes trigger expensive calculation" ;
rdfs:comment """
Input ports only. Indicates that any changes to the port value may
trigger expensive background calculation (eg. regenerate some lookup
tables in background thread). Any value changes may have not have
immediate effect at all, or may cause silence or diminished-quality
version of the output data to be produced until background processing is
finished. Ports having that property are typically not well suited for
connection to outputs of other plugins, and should not be offered as
connection targets or for automation by default.
""" .
:causesArtifacts a :PortProperty ;
rdfs:label "May cause audio artifacts when changed" ;
rdfs:comment """
Input ports only. Indicates that any changes to the port value may
produce slight artifacts to produced audio signals (zipper noise and
other results of signal discontinuities). Connecting ports of this type
to continuous signals is not recommended, and when presenting a list of
automation targets, those ports may be marked as artifact-producing.
""" .
:continuousCV a :PortProperty ;
rdfs:label "Carries a smooth modulation signal" ;
rdfs:comment """
Indicates that the port carries a "smooth" modulation signal. Control
input ports of this type are well-suited for being connected to sources
of smooth signals (knobs with smoothing, modulation rate oscillators,
output ports with continuousCV type etc). Typically, a plugin with this
type of ports will implement appropriate smoothing to avoid audio artifacts.
""" .
:discreteCV a :PortProperty ;
rdfs:label "Carries a discrete modulation signal" ;
rdfs:comment """
Indicates that the port carries a "discrete" modulation signal. Input
ports of this type are well-suited for being connected to sources of
discrete signals (switches, buttons, classifiers, event detectors etc.).
May be combined with :trigger property.
""" .
Some of the above come up in #lad from time to time, but I don't think
anybody tried to convert those raw ideas into .ttl before, so I decided
to do it instead.
Krzysztof
10 Jun
10 Jun
6:31 a.m.
New subject: More proposed LV2 addition/extension stuff
Krzysztof Foltman <wdev(a)foltman.com> writes:
Steve Harris wrote:
Having these things defined (either as part of core or as extension(s))
would be very useful. Hosts rendering generic UIs like zynjacku will use
them for sure.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
You're right, we never defined the lv2:binary
predicate.
While you're adding stuff to lv2core, you might as well consider adding
some of those (+/- any discussions that arise and probably rewrite in
proper English), or perhaps I should move some of them into separate
extension(s):
:trigger a :PortProperty ;
rdfs:label "Trigger" ;
rdfs:comment """
Indicates that the data item should be considered a Boolean value
corresponding to the specific event that was detected (control output
ports) or is to be triggered (control input ports). For input ports, the
port needs to be reset to false by the host (any value less or equal
than 0) after run() function is called.
""" .
(Boolean? discrete? based on if :integer or :toggle is present? a
feature that says :trigger that is supported? use special labeled events
instead?)
:supportsStrictBounds a :Feature
rdfs:label "Supports strict bounds" ;
rdfs:comment """
Indicates use of host support for :hasStrictBounds port property. A
plugin that specifies it as optional feature can omit value clamping for
:hasStrictBounds ports, if the feature is supported by the host. When
specified as required feature, it indicates that the plugin does not do
any clamping for input ports that have a :hasStrictBounds property.
""" .
:hasStrictBounds a :PortProperty ;
rdfs:label "Has strict bounds" ;
rdfs:comment """
For hosts supporting the :supportsStrictBounds, it indicates that the
value of the port should never exceed port's minimum and maximum control
points. For input ports, it moves the responsibility for limiting the
range of values to host, if it supports :supportsStrictBounds. For
output ports, it indicates that values within specified range are to be
expected, and breaking that should be considered by the host as error in
plugin implementation.
""" .
These probably belong somewhere else, but I'll post them anyway:
:expensive a :PortProperty ;
rdfs:label "Changes trigger expensive calculation" ;
rdfs:comment """
Input ports only. Indicates that any changes to the port value may
trigger expensive background calculation (eg. regenerate some lookup
tables in background thread). Any value changes may have not have
immediate effect at all, or may cause silence or diminished-quality
version of the output data to be produced until background processing is
finished. Ports having that property are typically not well suited for
connection to outputs of other plugins, and should not be offered as
connection targets or for automation by default.
""" .
:causesArtifacts a :PortProperty ;
rdfs:label "May cause audio artifacts when changed" ;
rdfs:comment """
Input ports only. Indicates that any changes to the port value may
produce slight artifacts to produced audio signals (zipper noise and
other results of signal discontinuities). Connecting ports of this type
to continuous signals is not recommended, and when presenting a list of
automation targets, those ports may be marked as artifact-producing.
""" .
:continuousCV a :PortProperty ;
rdfs:label "Carries a smooth modulation signal" ;
rdfs:comment """
Indicates that the port carries a "smooth" modulation signal. Control
input ports of this type are well-suited for being connected to sources
of smooth signals (knobs with smoothing, modulation rate oscillators,
output ports with continuousCV type etc). Typically, a plugin with this
type of ports will implement appropriate smoothing to avoid audio artifacts.
""" .
:discreteCV a :PortProperty ;
rdfs:label "Carries a discrete modulation signal" ;
rdfs:comment """
Indicates that the port carries a "discrete" modulation signal. Input
ports of this type are well-suited for being connected to sources of
discrete signals (switches, buttons, classifiers, event detectors etc.).
May be combined with :trigger property.
""" .
6007
days inactive
6010
days old
linux-audio-dev@lists.linuxaudio.org
7 comments
4 participants
participants (4)
-
Krzysztof Foltman -
Nedko Arnaudov -
Stefano D'Angelo -
Steve Harris