20 Jun
2006
20 Jun
'06
5:51 a.m.
There's been little news on the LV2 front here recently, all the disucssion
seems to have taken place on IRC, so a quick update:
Theres now a website: http://lv2plug.in/ as of a couple od days ago,
thanks to Thorsten Wilms which has links to drafts of the C header file
and RDF/Turtle schema. Please read the formal specs and comment.
Following discussion on the l-a-u list and hard work by a lot of people
there's a logo. Please don't discuss the logo except to praise it ;)
choosing one was quite involved. Various generic forms (black on white
etc.) will be availble on the website in due course.
TODO list:
* Finalise the technical aspect of the spec, get interested parties to
confirm that it meets thier needs (or at least doesn't prevent them).
* Write human language specification to go with .h and .ttl explaining
how to use the spec, conventions etc.
* Make sure there's a reasonable set of reference implementations and
examples.
* Test the extension mechanisms.
* Publish final spec, have tea and cakes etc.
- Steve
20 Jun
20 Jun
11:39 a.m.
On Tue, 2006-06-20 at 08:51 +0100, Steve Harris wrote:
There's been little news on the LV2 front here
recently, all the disucssion
seems to have taken place on IRC, so a quick update:
Theres now a website: http://lv2plug.in/ as of a couple od days ago,
thanks to Thorsten Wilms which has links to drafts of the C header file
and RDF/Turtle schema. Please read the formal specs and comment.
Following discussion on the l-a-u list and hard work by a lot of people
there's a logo. Please don't discuss the logo except to praise it ;)
choosing one was quite involved. Various generic forms (black on white
etc.) will be availble on the website in due course.
TODO list:
* Finalise the technical aspect of the spec, get interested parties to
confirm that it meets thier needs (or at least doesn't prevent them).
* Write human language specification to go with .h and .ttl explaining
how to use the spec, conventions etc.
* Make sure there's a reasonable set of reference implementations and
examples.
* Test the extension mechanisms.
* Publish final spec, have tea and cakes etc.
* Figure out what to do about plugin latency
I think plugins with latency should be required to provide latency
information to a control output port (like the convention for LADSPA).
The best way to do this IMO is to list the port in the RDF file, since
reserving a port symbol is pretty dirty and un LV2ey.. there's probably
other 'special' ports that will come along due to extensions, and
reserving their symbols is a bad slippery slope to step on to.
I can make the plugin validating host check the latency primitively (eg
run a single sample through the buffer) and fail if it isn't reported
correctly, so we're sure the LADSPA latency woes are gone.
-DR-
12:26 p.m.
On Tue, Jun 20, 2006 at 09:39:30 -0400, Dave Robillard wrote:
I can make the plugin validating host check the
latency primitively (eg
run a single sample through the buffer) and fail if it isn't reported
correctly, so we're sure the LADSPA latency woes are gone.
What if it's a delay line? I think you have to reply on the concience of
plugin programmers to get it right.
- Steve
1 p.m.
On Tue, 2006-06-20 at 15:26 +0100, Steve Harris wrote:
On Tue, Jun 20, 2006 at 09:39:30 -0400, Dave Robillard
wrote:
we could require plugins that delay the signal but are not latent to
have the required port (which would report zero)
I can make the plugin validating host check the
latency primitively (eg
run a single sample through the buffer) and fail if it isn't reported
correctly, so we're sure the LADSPA latency woes are gone.
What if it's a delay line? I think you have to reply on the concience of
plugin programmers to get it right.
3:50 p.m.
On Tue, 2006-06-20 at 10:58 -0400, Paul Davis wrote:
On Tue, 2006-06-20 at 15:26 +0100, Steve Harris wrote:
Hm, yeah, that would at least allow the verifier to check that plugins
without a latency port aren't latent, which is nice (and that's the main
problem anyway)
-DR-
On Tue, Jun 20, 2006 at 09:39:30 -0400, Dave
Robillard wrote:
we could require plugins that delay the signal but are not latent to
have the required port (which would report zero) I can make the plugin validating host check the
latency primitively (eg
run a single sample through the buffer) and fail if it isn't reported
correctly, so we're sure the LADSPA latency woes are gone.
What if it's a delay line? I think you have to reply on the concience of
plugin programmers to get it right. 
4:38 p.m.
On Tue, 2006-06-20 at 10:58 -0400, Paul Davis wrote:
On Tue, 2006-06-20 at 15:26 +0100, Steve Harris wrote:
Still a bit hackish for my tastes. The plugin reporting it's latency all
by it self is the-right-thing-to-do (tm). If hosts need to measure the
latency, it gets hairy. The hosts would need to take measurements every
time a plugin parameter changes, etc..
Let's just standardize an extension for latency ports after the release
of LV2. And let's do it FAST, so that most plugin writers will be
porting their plugins with the extension in place.
--
Sampo Savolainen <v2(a)iki.fi>
On Tue, Jun 20, 2006 at 09:39:30 -0400, Dave
Robillard wrote:
we could require plugins that delay the signal but are not latent to
have the required port (which would report zero) I can make the plugin validating host check the
latency primitively (eg
run a single sample through the buffer) and fail if it isn't reported
correctly, so we're sure the LADSPA latency woes are gone.
What if it's a delay line? I think you have to reply on the concience of
plugin programmers to get it right.
4:46 p.m.
On Tue, 2006-06-20 at 21:37 +0300, Sampo Savolainen wrote:
On Tue, 2006-06-20 at 10:58 -0400, Paul Davis wrote:
I think this should be included in the spec, since it's devastating when
plugins don't adhere. I believe Steve agrees with me (Steve?)
-DR-
On Tue, 2006-06-20 at 15:26 +0100, Steve Harris
wrote:
Still a bit hackish for my tastes. The plugin reporting it's latency all
by it self is the-right-thing-to-do (tm). If hosts need to measure the
latency, it gets hairy. The hosts would need to take measurements every
time a plugin parameter changes, etc..
Let's just standardize an extension for latency ports after the release
of LV2. And let's do it FAST, so that most plugin writers will be
porting their plugins with the extension in place. On Tue, Jun 20, 2006 at 09:39:30 -0400, Dave
Robillard wrote:
we could require plugins that delay the signal but are not latent to
have the required port (which would report zero) I can make the plugin validating host check the
latency primitively (eg
run a single sample through the buffer) and fail if it isn't reported
correctly, so we're sure the LADSPA latency woes are gone.
What if it's a delay line? I think you have to reply on the concience of
plugin programmers to get it right.
5:28 p.m.
On Tue, Jun 20, 2006 at 02:46:37 -0400, Dave Robillard wrote:
It doesnt need to be an extension really, as it was common practice in
LADSPA, just pick a URI for the hint and put it in the schema.
lv2:latencySamples anyone?
- Steve
Let's just
standardize an extension for latency ports after the release
of LV2. And let's do it FAST, so that most plugin writers will be
porting their plugins with the extension in place.
I think this should be included in the spec, since it's devastating when
plugins don't adhere. I believe Steve agrees with me (Steve?)
3:46 p.m.
On Tue, 2006-06-20 at 15:26 +0100, Steve Harris wrote:
On Tue, Jun 20, 2006 at 09:39:30 -0400, Dave Robillard
wrote:
Hmm. Good point. :/
-DR-
I can make the plugin validating host check the
latency primitively (eg
run a single sample through the buffer) and fail if it isn't reported
correctly, so we're sure the LADSPA latency woes are gone.
What if it's a delay line? I think you have to reply on the concience of
plugin programmers to get it right.
7077
days inactive
7077
days old
linux-audio-dev@lists.linuxaudio.org
8 comments
4 participants
participants (4)
-
Dave Robillard -
Paul Davis -
Sampo Savolainen -
Steve Harris