14 Jun
2009
14 Jun
'09
4:38 p.m.
hi everyone!
sorry if this has been discussed before, but i didn't find anything in
the archives...
consider the case of periodic control values of LADSPA plugins, for
instance the azimuth in a horizontal panner or the phase shift in a phaser.
currently, they are usually marked as BOUNDED_BELOW and BOUNDED_ABOVE,
but the host has no way of knowing that the upper bound is next to the
lower bound, so that it can chose the shortest path to the next value
when interpolating automation control points.
take ardour, for example: if i want to spin a source 360 degrees, i have
to start at 0, set a control point at 180, set another control point at
the exact next sample to -180 and then onwards. if there is even a
single sample between the control points, the interpolation will cause
the image to jump in weird ways, because it doesn't know that 180 == -180.
does it make sense to add a new hint to LADSPA, something like
LADSPA_HINT_PERIODIC? it would mandate LADSPA_HINT_BOUNDED_BELOW and
LADSPA_HINT_BOUNDED_ABOVE as well as the respective port range hints,
*and* imply that LowerBound is equivalent to UpperBound in the port
range hint structure.
this would enable hosts to do the Right Thing(tm).
best,
jörn
14 Jun
14 Jun
5:35 p.m.
On Sat, Jun 13, 2009 at 01:46:47PM +0200, Jörn Nettingsmeier wrote:
hi everyone!
sorry if this has been discussed before, but i didn't find anything in
the archives...
consider the case of periodic control values of LADSPA plugins, for
instance the azimuth in a horizontal panner or the phase shift in a phaser.
currently, they are usually marked as BOUNDED_BELOW and BOUNDED_ABOVE,
but the host has no way of knowing that the upper bound is next to the
lower bound, so that it can chose the shortest path to the next value
when interpolating automation control points.
take ardour, for example: if i want to spin a source 360 degrees, i have
to start at 0, set a control point at 180, set another control point at
the exact next sample to -180 and then onwards. if there is even a
single sample between the control points, the interpolation will cause
the image to jump in weird ways, because it doesn't know that 180 == -180.
does it make sense to add a new hint to LADSPA, something like
LADSPA_HINT_PERIODIC? it would mandate LADSPA_HINT_BOUNDED_BELOW and
LADSPA_HINT_BOUNDED_ABOVE as well as the respective port range hints,
*and* imply that LowerBound is equivalent to UpperBound in the port
range hint structure.
this would enable hosts to do the Right Thing(tm).
Would make perfect sense, and there are lots of spare bits
in the hints word.
And I'll repeat my proposal of almost 5 years ago:
- Add a 'enumerated' bit to the hints, used together with
'integer'.
- Add the required strings at the end of the port names
array, where it is trivially easy for a host to find
them (or ignore them if the host doesn't know about
the new bit).
Ciao,
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
5:44 p.m.
2009/6/13 Jörn Nettingsmeier <nettings(a)folkwang-hochschule.de>de>:
hi everyone!
sorry if this has been discussed before, but i didn't find anything in
the archives...
consider the case of periodic control values of LADSPA plugins, for
instance the azimuth in a horizontal panner or the phase shift in a phaser.
currently, they are usually marked as BOUNDED_BELOW and BOUNDED_ABOVE,
but the host has no way of knowing that the upper bound is next to the
lower bound, so that it can chose the shortest path to the next value
when interpolating automation control points.
take ardour, for example: if i want to spin a source 360 degrees, i have
to start at 0, set a control point at 180, set another control point at
the exact next sample to -180 and then onwards. if there is even a
single sample between the control points, the interpolation will cause
the image to jump in weird ways, because it doesn't know that 180 == -180.
does it make sense to add a new hint to LADSPA, something like
LADSPA_HINT_PERIODIC? it would mandate LADSPA_HINT_BOUNDED_BELOW and
LADSPA_HINT_BOUNDED_ABOVE as well as the respective port range hints,
*and* imply that LowerBound is equivalent to UpperBound in the port
range hint structure.
this would enable hosts to do the Right Thing(tm).
Hi,
I think it makes no sense nowadays to do something like that, for two reasons:
* LADSPA is old, hence old LADSPA hosts will not support that and
new/maintained ones are not likely to support that, since many are
focusing on newer APIs;
* An LV2 extension would allow you to do that quite easily in LV2,
which is probably preferable these days.
That said, I can already hear people who disagree with me shouting and
screaming.
Stefano
5:55 p.m.
On Sun, Jun 14, 2009 at 11:44:11PM +0200, Stefano D'Angelo wrote:
* LADSPA is old, hence old LADSPA hosts will not
support that and
new/maintained ones are not likely to support that, since many are
focusing on newer APIs;
They would just ingnore LADSPA them ?
* An LV2 extension would allow you to do that quite
easily in LV2,
which is probably preferable these days.
That said, I can already hear people who disagree with me shouting and
screaming.
<whisper> Since it's useful, doesn't break anything, and trivially
easy, there is no reason for not adding such a bit. </whisper>
Ciao,
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
6:07 p.m.
2009/6/14 Fons Adriaensen <fons(a)kokkinizita.net>et>:
On Sun, Jun 14, 2009 at 11:44:11PM +0200, Stefano
D'Angelo wrote:
If it is added to the next version LADSPA itself, then it's fine,
otherwise anyone could think like that and you can imagine the
*POTENTIAL* mess.
Stefano
* LADSPA is old, hence old LADSPA hosts will not
support that and
new/maintained ones are not likely to support that, since many are
focusing on newer APIs;
They would just ingnore LADSPA them ?
* An LV2 extension would allow you to do that
quite easily in LV2,
which is probably preferable these days.
That said, I can already hear people who disagree with me shouting and
screaming.
<whisper> Since it's useful, doesn't break anything, and trivially
easy, there is no reason for not adding such a bit. </whisper> 
15 Jun
15 Jun
2:31 a.m.
Stefano D'Angelo wrote:
I think way too many things in Linux audio are concerned about potential
this and potential that, all while ignoring real problems/deficiencies.
Idealism taken to extremes and all that.
I already support enums in LADSPA via LRDF, but someone introduced those
two bits and they were done "properly" (without breaking anything that
used to work before), I'd support them in Calf, too.
Krzysztof
<whisper> Since it's useful, doesn't break anything, and trivially
easy, there is no reason for not adding such a bit. </whisper>
If it is added to the next version LADSPA itself, then it's fine,
otherwise anyone could think like that and you can imagine the
*POTENTIAL* mess.
4:05 a.m.
2009/6/15 Krzysztof Foltman <wdev(a)foltman.com>om>:
Stefano D'Angelo wrote:
I think way too many things in Linux audio are concerned about potential
this and potential that, all while ignoring real problems/deficiencies.
Idealism taken to extremes and all that.
Well, I just misread the original post (somehow I thought Jorn wanted
to add the hint outside of the LADSPA spec, that would cause lots of
problems).
<whisper> Since it's useful, doesn't break anything, and trivially
easy, there is no reason for not adding such a bit. </whisper>
If it is added to the next version LADSPA itself, then it's fine,
otherwise anyone could think like that and you can imagine the
*POTENTIAL* mess.
I already support enums in LADSPA via LRDF, but
someone introduced those two
bits and they were done "properly" (without breaking anything that used to
work before), I'd support them in Calf, too.
Two bits?
Stefano
P.S.: Regarding LV2 Calf plugins, could you use urn:ladspa:12345-style
URIs as specified here
(http://lv2plug.in/docs/index.php?title=Replace_plugin) for
dc:replace? ;-)
4:39 a.m.
Stefano D'Angelo wrote:
Well, I just misread the original post (somehow I
thought Jorn wanted
to add the hint outside of the LADSPA spec, that would cause lots of
problems).
Lots of problems? What sort of?
If you mean hordes of people suddenly starting to define their own
proprietary undocumented conflicting port hints and hidden strings...
wake up :)
We don't see people flooding the LV2 Wiki with new port hint proposals.
And it's much easier to define new port hints in LV2 than it is in LADSPA.
Two bits?
Flags, port hints, bits, YKWIM.
P.S.: Regarding LV2 Calf plugins, could you use
urn:ladspa:12345-style
URIs as specified here
(http://lv2plug.in/docs/index.php?title=Replace_plugin) for
dc:replace? ;-)
Yes.
Krzysztof
5:09 a.m.
2009/6/15 Krzysztof Foltman <wdev(a)foltman.com>om>:
Stefano D'Angelo wrote:
You do not need "hordes of people", you just need two trying to define
the same bit differently :-)
Stefano
Well, I just misread the original post (somehow I
thought Jorn wanted
to add the hint outside of the LADSPA spec, that would cause lots of
problems).
Lots of problems? What sort of?
If you mean hordes of people suddenly starting to define their own
proprietary undocumented conflicting port hints and hidden strings...
wake up :)
We don't see people flooding the LV2 Wiki with new port hint proposals.
And it's much easier to define new port hints in LV2 than it is in LADSPA. 
12:08 p.m.
On Sun, 2009-06-14 at 23:44 +0200, Stefano D'Angelo wrote:
2009/6/13 Jörn Nettingsmeier
<nettings(a)folkwang-hochschule.de>de>:
[...]
> sorry if this has been discussed before, but i
didn't find anything in
> the archives...
> consider the case of periodic control values of LADSPA plugins, for
> instance the azimuth in a horizontal panner or the phase shift in a phaser.
> currently, they are usually marked as BOUNDED_BELOW and BOUNDED_ABOVE,
> but the host has no way of knowing that the upper bound is next to the
> lower bound, so that it can chose the shortest path to the next value
> when interpolating automation control points.
[...]
* An LV2 extension would allow you to do that quite
easily in LV2,
which is probably preferable these days.
Maybe belongs in the units extension?
-dr
12:28 p.m.
2009/6/15 David Robillard <dave(a)drobilla.net>et>:
On Sun, 2009-06-14 at 23:44 +0200, Stefano
D'Angelo wrote:
I don't think so: periodicity and units are quite different things.
For example: an angle could be used also to indicate direction (-180°
!= 180°) or distance in space (0° != 360°), while integers for example
could be cyclic (rhythms, tones/semitones/harmony, musical cycles,
etc.)...
Stefano
2009/6/13 Jörn Nettingsmeier
<nettings(a)folkwang-hochschule.de>de>:
[...]
> sorry if this has been discussed before, but
i didn't find anything in
> the archives...
> consider the case of periodic control values of LADSPA plugins, for
> instance the azimuth in a horizontal panner or the phase shift in a phaser.
> currently, they are usually marked as BOUNDED_BELOW and BOUNDED_ABOVE,
> but the host has no way of knowing that the upper bound is next to the
> lower bound, so that it can chose the shortest path to the next value
> when interpolating automation control points.
[...]
* An LV2 extension would allow you to do that
quite easily in LV2,
which is probably preferable these days.
Maybe belongs in the units extension?
5:08 p.m.
On Mon, 2009-06-15 at 18:28 +0200, Stefano D'Angelo wrote:
2009/6/15 David Robillard <dave(a)drobilla.net>et>:
Sounds an awful lot like units to me... "degrees out of 360" is a cyclic
unit
-dr
On Sun, 2009-06-14 at 23:44 +0200, Stefano
D'Angelo wrote:
I don't think so: periodicity and units are quite different things.
For example: an angle could be used also to indicate direction (-180°
!= 180°) or distance in space (0° != 360°), while integers for example
could be cyclic (rhythms, tones/semitones/harmony, musical cycles,
etc.)... 2009/6/13 Jörn Nettingsmeier
<nettings(a)folkwang-hochschule.de>de>:
[...]
> sorry if this has been discussed before, but
i didn't find anything in
> the archives...
> consider the case of periodic control values of LADSPA plugins, for
> instance the azimuth in a horizontal panner or the phase shift in a phaser.
> currently, they are usually marked as BOUNDED_BELOW and BOUNDED_ABOVE,
> but the host has no way of knowing that the upper bound is next to the
> lower bound, so that it can chose the shortest path to the next value
> when interpolating automation control points.
[...]
* An LV2 extension would allow you to do that
quite easily in LV2,
which is probably preferable these days.
Maybe belongs in the units extension? 
16 Jun
16 Jun
1:07 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
David Robillard wrote:
On Mon, 2009-06-15 at 18:28 +0200, Stefano
D'Angelo wrote:
Yes, but there is a bit more to it too. As input controls have a min/max they are rendered
UI as either a slider or knob with a fixed upper
and lower bound that cannot be transgressed. This isn't true for a cyclic parameter.
Although the values produced will be in some range (0
- -> 360, -pi -> pi, -1 -> 1) a UI knob would have no limits placed on it's
movement (slider won't cut it here) - it can go round past the max
or below the min (max and min are actually the same point).
Obviously there is more that just rendering the UI, the host would need to know there are
two paths to between points on a cyclic control
and hence must have a method for choosing the direction with automation etc (remember
direction along with values?). It would be nice if it
also took care of shifting values to within the the desired range but a plugin with a
cyclic parameter should be able to do the shifting itself.
Declaring the control as being in some angle UOM isn't enough to know if the control
is cyclic, as the values may just represent an arc (and
why stop at just angle UOMs), there would need to be a flag to indicate to the host that a
control is cyclic so that it could handle it
properly.
IMO if this is required it's a PortProperty.
regards,
Fraser
2009/6/15 David Robillard
<dave(a)drobilla.net>et>:
Sounds an awful lot like units to me... "degrees out of 360" is a cyclic
unit On Sun, 2009-06-14 at 23:44 +0200, Stefano
D'Angelo wrote:
I don't think so: periodicity and units are quite different things.
For example: an angle could be used also to indicate direction (-180°
!= 180°) or distance in space (0° != 360°), while integers for example
could be cyclic (rhythms, tones/semitones/harmony, musical cycles,
etc.)... 2009/6/13 Jörn Nettingsmeier
<nettings(a)folkwang-hochschule.de>de>:
[...]
> sorry if this has been discussed before, but
i didn't find anything in
> the archives...
> consider the case of periodic control values of LADSPA plugins, for
> instance the azimuth in a horizontal panner or the phase shift in a phaser.
> currently, they are usually marked as BOUNDED_BELOW and BOUNDED_ABOVE,
> but the host has no way of knowing that the upper bound is next to the
> lower bound, so that it can chose the shortest path to the next value
> when interpolating automation control points.
[...]
* An LV2 extension would allow you to do that
quite easily in LV2,
which is probably preferable these days.
Maybe belongs in the units extension?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFKN9FFNZroiEh4erwRAg7wAKCvELQJ9ntNvJQVqIlcHPC+1KVEdwCfemPK
FFHIsKjQ6iGvYSkQD3rB/Nw=
=ybbB
-----END PGP SIGNATURE-----
18 Jun
18 Jun
12:20 p.m.
On Wed, 2009-06-17 at 03:07 +1000, Fraser wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
David Robillard wrote:
Good point
Sounds an awful lot like units to me...
"degrees out of 360" is a cyclic
unit
Declaring the control as being in some angle UOM isn't enough to know if the control
is cyclic, as the values may just represent an arc (and
why stop at just angle UOMs), there would need to be a flag to indicate to the host that
a control is cyclic so that it could handle it
properly. IMO if this is required it's a PortProperty.
Yeah, probably
-dr
19 Jun
19 Jun
3:10 p.m.
Stefano D'Angelo schrieb:
2009/6/13 Jörn Nettingsmeier
<nettings(a)folkwang-hochschule.de>de>:
I disagree. I would not mind adding support for more hints to the gstreamer
ladspa wrapper. Its not a lot of work and its good to have that now even if lv2
takes over in the long run.
The other think I'd like to have is hints for audio-port channel
grouping/mapping. That is describe that a port is the left-channel of stereo
pair named <xyz>, Even if this goes to the rdf.
Stefan
hi everyone!
sorry if this has been discussed before, but i didn't find anything in
the archives...
consider the case of periodic control values of LADSPA plugins, for
instance the azimuth in a horizontal panner or the phase shift in a phaser.
currently, they are usually marked as BOUNDED_BELOW and BOUNDED_ABOVE,
but the host has no way of knowing that the upper bound is next to the
lower bound, so that it can chose the shortest path to the next value
when interpolating automation control points.
take ardour, for example: if i want to spin a source 360 degrees, i have
to start at 0, set a control point at 180, set another control point at
the exact next sample to -180 and then onwards. if there is even a
single sample between the control points, the interpolation will cause
the image to jump in weird ways, because it doesn't know that 180 == -180.
does it make sense to add a new hint to LADSPA, something like
LADSPA_HINT_PERIODIC? it would mandate LADSPA_HINT_BOUNDED_BELOW and
LADSPA_HINT_BOUNDED_ABOVE as well as the respective port range hints,
*and* imply that LowerBound is equivalent to UpperBound in the port
range hint structure.
this would enable hosts to do the Right Thing(tm).
Hi,
I think it makes no sense nowadays to do something like that, for two reasons:
* LADSPA is old, hence old LADSPA hosts will not support that and
new/maintained ones are not likely to support that, since many are
focusing on newer APIs;
* An LV2 extension would allow you to do that quite easily in LV2,
which is probably preferable these days.
That said, I can already hear people who disagree with me shouting and
screaming.
Stefano
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
3:23 p.m.
2009/6/19 Stefan Kost <ensonic(a)hora-obscura.de>de>:
Stefano D'Angelo schrieb:
Stefan, once again, I originally misunderstood the post by Jorn
thinking he wanted to add that stuff outside of the LADSPA header, the
discussion went and is still going on.
Stefano
2009/6/13 Jörn Nettingsmeier
<nettings(a)folkwang-hochschule.de>de>:
I disagree. I would not mind adding support for more hints to the gstreamer
ladspa wrapper. Its not a lot of work and its good to have that now even if lv2
takes over in the long run.
The other think I'd like to have is hints for audio-port channel
grouping/mapping. That is describe that a port is the left-channel of stereo
pair named <xyz>, Even if this goes to the rdf.
Stefan hi everyone!
sorry if this has been discussed before, but i didn't find anything in
the archives...
consider the case of periodic control values of LADSPA plugins, for
instance the azimuth in a horizontal panner or the phase shift in a phaser.
currently, they are usually marked as BOUNDED_BELOW and BOUNDED_ABOVE,
but the host has no way of knowing that the upper bound is next to the
lower bound, so that it can chose the shortest path to the next value
when interpolating automation control points.
take ardour, for example: if i want to spin a source 360 degrees, i have
to start at 0, set a control point at 180, set another control point at
the exact next sample to -180 and then onwards. if there is even a
single sample between the control points, the interpolation will cause
the image to jump in weird ways, because it doesn't know that 180 == -180.
does it make sense to add a new hint to LADSPA, something like
LADSPA_HINT_PERIODIC? it would mandate LADSPA_HINT_BOUNDED_BELOW and
LADSPA_HINT_BOUNDED_ABOVE as well as the respective port range hints,
*and* imply that LowerBound is equivalent to UpperBound in the port
range hint structure.
this would enable hosts to do the Right Thing(tm).
Hi,
I think it makes no sense nowadays to do something like that, for two reasons:
* LADSPA is old, hence old LADSPA hosts will not support that and
new/maintained ones are not likely to support that, since many are
focusing on newer APIs;
* An LV2 extension would allow you to do that quite easily in LV2,
which is probably preferable these days.
That said, I can already hear people who disagree with me shouting and
screaming. 
16 Jun
16 Jun
2:45 p.m.
On Sat, 2009-06-13 at 13:46 +0200, Jörn Nettingsmeier wrote:
consider the case of periodic control values of LADSPA
plugins, for
instance the azimuth in a horizontal panner or the phase shift in a phaser.
I don't know if this would be of any use to you, but I have a physical
controller that sends messages about its full circular direction. I've
made to work with midi like this;
1) The circle is a square mapped to two controlvalues Left/Right
Front/Back. You start at the center of Front, walk all the way to the
Right then all the way to the Back then to the Left and back to Front
again. Pretty much what a joystick would do in its extreme positions and
works well with existing gear. Recommended!
2) Still two controllers, one sends the initial angle where you
touchdown, the other sends delta values as you move around.
A bit harder to fit in with existing gear, unless you want to play your
faders like a violin :)
/j
18 Jun
18 Jun
11:47 a.m.
New subject: [SUMMARY] LADSPA extension for periodic control values?
hi everybody!
thanks for sharing your thoughts!
Jörn Nettingsmeier wrote:
consider the case of periodic control values of LADSPA
plugins, for
instance the azimuth in a horizontal panner or the phase shift in a phaser.
currently, they are usually marked as BOUNDED_BELOW and BOUNDED_ABOVE,
but the host has no way of knowing that the upper bound is next to the
lower bound, so that it can chose the shortest path to the next value
when interpolating automation control points.
take ardour, for example: if i want to spin a source 360 degrees, i have
to start at 0, set a control point at 180, set another control point at
the exact next sample to -180 and then onwards. if there is even a
single sample between the control points, the interpolation will cause
the image to jump in weird ways, because it doesn't know that 180 == -180.
does it make sense to add a new hint to LADSPA, something like
LADSPA_HINT_PERIODIC? it would mandate LADSPA_HINT_BOUNDED_BELOW and
LADSPA_HINT_BOUNDED_ABOVE as well as the respective port range hints,
*and* imply that LowerBound is equivalent to UpperBound in the port
range hint structure.
this would enable hosts to do the Right Thing(tm).
to summarize: there seem to be no objections to adding such a hint
(stefano's initial critique was about just using it without adding it to
the standard LADSPA header, iiuc, which has never been intended).
some people opined that it could as well be done in LV2 using an
extension. there is no consensus yet about whether this belongs in the
existing units extension, but this is orthogonal to the LADSPA issue.
during the discussion, fons brought up the issue of adding an enum type
to integer ports, to enable hosts to display meaningful string values
for radio-button-type controls. the general usefulness of this was
undebated.
an RFC for a LADSPA 1.2 revision including both the "periodic" and the
"enum" hints will be posted in a new thread.
best,
jörn
12:10 p.m.
New subject: [SUMMARY] LADSPA extension for periodic control values?
2009/6/18 Jörn Nettingsmeier <nettings(a)folkwang-hochschule.de>
hi everybody!
thanks for sharing your thoughts!
Jörn Nettingsmeier wrote:
Yeah, I just misread your original post, sorry.
some people opined that it could as well be done in LV2 using an
consider the case of periodic control values of
LADSPA plugins, for
instance the azimuth in a horizontal panner or the phase shift in a
phaser.
currently, they are usually marked as
BOUNDED_BELOW and BOUNDED_ABOVE,
but the host has no way of knowing that the upper bound is next to the
lower bound, so that it can chose the shortest path to the next value
when interpolating automation control points.
take ardour, for example: if i want to spin a source 360 degrees, i have
to start at 0, set a control point at 180, set another control point at
the exact next sample to -180 and then onwards. if there is even a
single sample between the control points, the interpolation will cause
the image to jump in weird ways, because it doesn't know that 180 ==
-180.
does it make sense to add a new hint to LADSPA, something like
LADSPA_HINT_PERIODIC? it would mandate LADSPA_HINT_BOUNDED_BELOW and
LADSPA_HINT_BOUNDED_ABOVE as well as the respective port range hints,
*and* imply that LowerBound is equivalent to UpperBound in the port
range hint structure.
this would enable hosts to do the Right Thing(tm).
to summarize: there seem to be no objections to adding such a hint
(stefano's initial critique was about just using it without adding it to
the standard LADSPA header, iiuc, which has never been intended).
extension. there is no consensus yet about whether
this belongs in the
existing units extension, but this is orthogonal to the LADSPA issue.
during the discussion, fons brought up the issue of adding an enum type
to integer ports, to enable hosts to display meaningful string values
for radio-button-type controls. the general usefulness of this was
undebated.
an RFC for a LADSPA 1.2 revision including both the "periodic" and the
"enum" hints will be posted in a new thread.
You might want to talk to Richard Furse as well about this, who is the
author of LADSPA and IIRC he told me he wasn't reading LAD mails lately. You
can find his email at the bottom of the main www.ladspa.org page.
Stefano
1:59 p.m.
New subject: [SUMMARY] LADSPA extension for periodic control values?
2009/6/18 Stefano D'Angelo <zanga.mail(a)gmail.com>om>:
You might want to talk to Richard Furse as well about this, who is the
author of LADSPA and IIRC he told me he wasn't reading LAD mails lately. You
can find his email at the bottom of the main www.ladspa.org page.
Richard is one of the authors of LADSPA.
Stephane Westerfeld and myself are also listed as authors. Richard has
almost nothing to do with LAD in several years. Stephane is still
involved in some ways, but not very active on LAD.
I submit that copyright or not, the 3 of us hold no veto over ladspa.h
- this header file really belongs to the LAD community.
--p
2:10 p.m.
New subject: [SUMMARY] LADSPA extension for periodic control values?
2009/6/18 Paul Davis <paul(a)linuxaudiosystems.com>
2009/6/18 Stefano D'Angelo
<zanga.mail(a)gmail.com>om>:
Sorry, I didn't know that. I usually don't pay too much attention to
copyright notices of LGPLed header files :-P
Stefano
P.S.: Paul, I don't know if you are interested, but recently LV2 hosts can
access LADSPA plugins (with full LRDF extra data support - except presets)
through the latest NASPRO hg revision and a LV2 "dynamic manifest"
specification, which the latest svn revision of SLV2 already supports...
could this be of any interest to Ardour? (I tested it on Traverso, and it
all seems to work - except for a weird problem with Traverso/Qt when
creating a GUI for CALF plugins - I have no time to investigate this ATM).
You might want to talk to Richard Furse as well about this, who is the
author of LADSPA and IIRC he told me he wasn't reading LAD mails lately.
You
can find his email at the bottom of the main
www.ladspa.org page.
Richard is one of the authors of LADSPA.
Stephane Westerfeld and myself are also listed as authors. Richard has
almost nothing to do with LAD in several years. Stephane is still
involved in some ways, but not very active on LAD.
I submit that copyright or not, the 3 of us hold no veto over ladspa.h
- this header file really belongs to the LAD community.
5430
days inactive
5435
days old
linux-audio-dev@lists.linuxaudio.org
21 comments
9 participants
participants (9)
-
David Robillard -
Fons Adriaensen -
Fraser -
Jens M Andreasen -
Jörn Nettingsmeier -
Krzysztof Foltman -
Paul Davis -
Stefan Kost -
Stefano D'Angelo