26 Mar
2011
26 Mar
'11
9:53 p.m.
The C* Audio Plugin Suite reaches version 0.4.5.
http://quitte.de/dsp/caps.html
http://quitte.de/dsp/caps_0.4.5.tar.gz
CAPS is a collection of refined LADSPA units covering a wide range of
applications, from stompbox classics to experimental oscillators.
CAPS is distributed as open source under the terms of the GNU Public
License.
-*-
This release brings a new plugin, "Narrower", which reduces the
perceived width of a stereophonic image. Frequent users of headphones
will appreciate the increased subtlety of the listening experience as
well as the reduced fatigue caused by "superstereo" recordings.
Other than that, some minor bugs have been fixed and the accompanying
PDF data sheet has been improved (frequency response plots now use log
scale: http://quitte.de/dsp/caps-0.4.5.pdf ).
The build configuration tool "configure.py" has been modified to
handle python3's errant ways in graceful manner.
Upgrading is recommended unless you have no need for the new plugin
and the current version is working fine for you.
-*-
Enjoy, and thank you for using CAPS,
Tim
26 Mar
26 Mar
11:36 p.m.
Hello Tim!
thanks for the new release. I love your plugins. Wouldn't know, where I'd be
without the chorus (1767) or the amp (1786) and occasionally a few of the
other ones as well. :-) Great suite of plugins. I never had any problems so
far, but I just istalled the new ones.
Warm regards
Julien
--------
Music was my first love and it will be my last (John Miles)
======== FIND MY WEB-PROJECT AT: ========
http://ltsb.sourceforge.net
the Linux TextBased Studio guide
======= AND MY PERSONAL PAGES AT: =======
http://www.juliencoder.de
28 Mar
28 Mar
2:02 a.m.
On Sat, Mar 26, 2011 at 8:41 PM, Julien Claassen <julien(a)c-lab.de> wrote:
Hello Tim!
thanks for the new release. I love your plugins. Wouldn't know, where I'd
be without the chorus (1767) or the amp (1786) and occasionally a few of the
other ones as well. :-) Great suite of plugins. I never had any problems so
far, but I just istalled the new ones.
Warm regards
Julien
I second this. CAPS is great.
One request though: would it be possible to add an AutoFilter plugin?
Basically, it would be the same as your AutoWah but with a low-pass
filter instead of band-pass. It's a common effect for bass guitar.
Thanks again!
8:22 p.m.
[Paul Coccoli]
On Sat, Mar 26, 2011 at 8:41 PM, Julien Claassen
<julien(a)c-lab.de> wrote:
Thank you Julien and Paul!
I'm planning to add a mode switch (low- or bandpass) to the AutoWah
instead of making a separate new plugin, or would that be a stupid
idea?
Cheers, Tim
Hello Tim!
thanks for the new release. I love your plugins. Wouldn't know, where I'd
be without the chorus (1767) or the amp (1786) and occasionally a few of the
other ones as well. :-) Great suite of plugins. I never had any problems so
far, but I just istalled the new ones.
Warm regards
Julien
I second this. CAPS is great.
One request though: would it be possible to add an AutoFilter plugin?
Basically, it would be the same as your AutoWah but with a low-pass
filter instead of band-pass. It's a common effect for bass guitar. 
10:09 p.m.
On Monday 28 March 2011 20.29.18 Tim Goetze wrote:
I'm planning to add a mode switch (low- or
bandpass) to the AutoWah
instead of making a separate new plugin, or would that be a stupid
idea?
I think that is ok if it works and behaves as before when one do not use the
new functionality (for backward compatibility). If not, then a name like
AutoWah-mkII or something is better when one still can use the old one.
Jostein
10:15 p.m.
2011/3/28 Tim Goetze <tim(a)quitte.de>de>:
[Paul Coccoli]
Aehm... there is a bug in the LRDF file, plugin CabinetI has two more
model entries than the port's minimum-maximum range supports.
On Sat, Mar 26, 2011 at 8:41 PM, Julien Claassen
<julien(a)c-lab.de> wrote:
Thank you Julien and Paul! Hello Tim!
thanks for the new release. I love your plugins. Wouldn't know, where I'd
be without the chorus (1767) or the amp (1786) and occasionally a few of the
other ones as well. :-) Great suite of plugins. I never had any problems so
far, but I just istalled the new ones.
Warm regards
Julien
I second this. CAPS is great.
One request though: would it be possible to add an AutoFilter plugin?
Basically, it would be the same as your AutoWah but with a low-pass
filter instead of band-pass. It's a common effect for bass guitar. I'm planning to add a mode switch (low- or
bandpass) to the AutoWah
instead of making a separate new plugin, or would that be a stupid
idea?
For compatibility with LV2, it's better if you create a new plugin for that...
Best regards,
Stefano D'Angelo
10:54 p.m.
[Stefano D'Angelo]
I don't see how compatibility with LV2 is a concern here?
Cheers, Tim
Aehm... there is a bug in the LRDF file, plugin
CabinetI has two more
model entries than the port's minimum-maximum range supports.
Thanks for spotting that. Fixed locally (along with filter mode ports
being incorrectly labeled 'model' in the RDF).
I'm
planning to add a mode switch (low- or bandpass) to the AutoWah
instead of making a separate new plugin, or would that be a stupid
idea?
For compatibility with LV2, it's better if you create a new plugin for that...
10:59 p.m.
2011/3/28 Tim Goetze <tim(a)quitte.de>de>:
I don't see how compatibility with LV2 is a concern here?
Heh... long story short: LV2 uses URIs, LADSPA uses UniqueIDs (not
necessarily but...), two LV2 plugins with same URI are required to
have the same "port signature" (i.e., ports) and I wrote a LADSPA to
LV2 bridge where the URIs of the bridged plugins are in the form
urn:ladspa:xxxx, where xxxx is the UniqueID.
This means, if you change the port signature and maintain the same
UniqueID, we would have incompatibilities in the LV2 world. If you
create a new plugin or don't touch ports, instead, everything's fine.
Stefano
I'm planning to add a mode switch (low- or
bandpass) to the AutoWah
instead of making a separate new plugin, or would that be a stupid
idea?
For compatibility with LV2, it's better if you create a new plugin for that... 
29 Mar
29 Mar
2:54 a.m.
Excerpts from Stefano D'Angelo's message of 2011-03-28 22:59:46 +0200:
2011/3/28 Tim Goetze <tim(a)quitte.de>de>:
I don't see how compatibility with LV2 is a concern here?
Heh... long story short: LV2 uses URIs, LADSPA uses UniqueIDs (not
necessarily but...), two LV2 plugins with same URI are required to
have the same "port signature" (i.e., ports) and I wrote a LADSPA to
LV2 bridge where the URIs of the bridged plugins are in the form
urn:ladspa:xxxx, where xxxx is the UniqueID.
This means, if you change the port signature and maintain the same
UniqueID, we would have incompatibilities in the LV2 world. If you
create a new plugin or don't touch ports, instead, everything's fine.
Stefano
I'd say you'd even have incompatibilities in LADSPA world. Even fixes in
LADSPA plugins would sometimes need a new ID (This was discussed a while
ago regarding a LADSPA that has an unintuitive port order).
I'm planning to add a mode switch (low- or
bandpass) to the AutoWah
instead of making a separate new plugin, or would that be a stupid
idea?
For compatibility with LV2, it's better if you create a new plugin for that...
8:52 p.m.
[Philipp Überbacher]
Excerpts from Stefano D'Angelo's message of
2011-03-28 22:59:46 +0200:
Lacking sufficient knowledge of all the LADSPA hosts out there, I'm
unable to judge how many will cope with the addition of a port to an
existing plugin and how many will not.
However, I'd expect any host on whose design reasonably deep thought
has been expended to simply use the new plugin in place of the
previous one, with the the new port set to its default value. In this
case the plugin will operate exactly the same way the old version did.
(For what it's worth, ladspa.h does not mandate that a plugins' port
signature never changes.)
It is very unfortunate that such a change might break the way your
bridge code works, Stefano, and I would like to apologise in advance.
(If the addition of a 'version' symbol exported by caps.so is any
help, I'll be happy to add that.)
Cheers, Tim
This means, if you change the port signature and maintain the same
UniqueID, we would have incompatibilities in the LV2 world. If you
create a new plugin or don't touch ports, instead, everything's fine.
Stefano
I'd say you'd even have incompatibilities in LADSPA world. Even fixes in
LADSPA plugins would sometimes need a new ID (This was discussed a while
ago regarding a LADSPA that has an unintuitive port order).
11:45 p.m.
Hi Tim,
2011/3/29 Tim Goetze <tim(a)quitte.de>de>:
It is very unfortunate that such a change might break
the way your
bridge code works, Stefano, and I would like to apologise in advance.
(If the addition of a 'version' symbol exported by caps.so is any
help, I'll be happy to add that.)
It's really nice when somebody speaks with respect the way you do,
Tim. I do immensely appreciate that. (And by the way, no need to
apologize).
Regarding the addition of a symbol, introducing something into LADSPA
(because if we agree on something, it's probably going to become a
generic mechanism in the end) is really something I would avoid. It
kind of both defeats the purpose of doing bridging well (i.e., no need
to make changes to existing stuff) and also it would be unfair to
recommend an addition to LADSPA without agreement from the whole
LADSPA community.
So for the moment I'm trying to imagine something that doesn't involve
adding stuff to LADSPA itself (maybe a text file or something), and in
the meanwhile feel free to ignore the issue. It's all on my back now.
If I come up with something I will let you know.
All the best,
Stefano
2 Apr
2 Apr
11:44 a.m.
[Stefano D'Angelo]
2011/3/29 Tim Goetze <tim(a)quitte.de>de>:
> It is very unfortunate that such a change might break the way your
> bridge code works, Stefano, and I would like to apologise in advance.
> (If the addition of a 'version' symbol exported by caps.so is any
> help, I'll be happy to add that.)
[...]
Regarding the addition of a symbol, introducing
something into LADSPA
(because if we agree on something, it's probably going to become a
generic mechanism in the end) is really something I would avoid. It
kind of both defeats the purpose of doing bridging well (i.e., no need
to make changes to existing stuff) and also it would be unfair to
recommend an addition to LADSPA without agreement from the whole
LADSPA community.
Thanks Stefano,
this extra symbol wouldn't be an addition to LADSPA itself. Instead,
it would be one private to caps.so, completely independent of the
plugin standard.
Like so, for example:
void * h = dlopen ("/path/to/caps.so", RTLD_LAZY);
/* assuming h is valid, check for caps */
const int * caps = (const int *) dlsym (h, "__caps_version__");
if (caps)
printf ("found caps version %d.%d.%d", caps[0], caps[1], caps[2]);
Should you consider special-casing for individual plugin libraries a
pragmatic and viable approach, I'd imagine something like this to be
helpful. (Put together, the caps library version and the UniqueID of
a plugin guarantee a stable port signature.)
Cheers, Tim
3 Apr
3 Apr
10:34 a.m.
2011/4/2 Tim Goetze <tim(a)quitte.de>de>:
[Stefano D'Angelo]
Ok, it seems like this is the best way to do it after all... in the
hope that this does not become a trend among LADSPA plugin authors.
Best regards,
Stefano
P.S.: using two version numbers instead of three could be of help in my case...
2011/3/29 Tim Goetze <tim(a)quitte.de>de>:
> It is very unfortunate that such a change might break the way your
> bridge code works, Stefano, and I would like to apologise in advance.
> (If the addition of a 'version' symbol exported by caps.so is any
> help, I'll be happy to add that.)
[...]
Regarding the addition of a symbol, introducing
something into LADSPA
(because if we agree on something, it's probably going to become a
generic mechanism in the end) is really something I would avoid. It
kind of both defeats the purpose of doing bridging well (i.e., no need
to make changes to existing stuff) and also it would be unfair to
recommend an addition to LADSPA without agreement from the whole
LADSPA community.
Thanks Stefano,
this extra symbol wouldn't be an addition to LADSPA itself. Instead,
it would be one private to caps.so, completely independent of the
plugin standard.
Like so, for example:
void * h = dlopen ("/path/to/caps.so", RTLD_LAZY);
/* assuming h is valid, check for caps */
const int * caps = (const int *) dlsym (h, "__caps_version__");
if (caps)
printf ("found caps version %d.%d.%d", caps[0], caps[1], caps[2]);
Should you consider special-casing for individual plugin libraries a
pragmatic and viable approach, I'd imagine something like this to be
helpful. (Put together, the caps library version and the UniqueID of
a plugin guarantee a stable port signature.) 
5 Apr
5 Apr
2:34 a.m.
On 03/04/11 04:34 AM, Stefano D'Angelo wrote:
2011/4/2 Tim Goetze<tim(a)quitte.de>de>:
Global identifiers beginning with __ are reserved for the C
implementation...
Might as well just use LADSPA as a prefix instead of CAPS, in case this
needs doing somewhere else... though this whole thing is extremely
awful, and I really hope that is not the case...
Another less awful option would be to somehow add the information to the
library that the port is connectionOptional...
-dr
P.S. Just to verify, the new port index will be a new index greater than
all the old ones, right?
[Stefano D'Angelo]
Ok, it seems like this is the best way to do it after all... in the
hope that this does not become a trend among LADSPA plugin authors.
Best regards,
Stefano
P.S.: using two version numbers instead of three could be of help in my case...
2011/3/29 Tim Goetze<tim(a)quitte.de>de>:
> It is very unfortunate that such a change might break the way your
> bridge code works, Stefano, and I would like to apologise in advance.
> (If the addition of a 'version' symbol exported by caps.so is any
> help, I'll be happy to add that.)
>
[...]
Regarding the addition of a symbol, introducing
something into LADSPA
(because if we agree on something, it's probably going to become a
generic mechanism in the end) is really something I would avoid. It
kind of both defeats the purpose of doing bridging well (i.e., no need
to make changes to existing stuff) and also it would be unfair to
recommend an addition to LADSPA without agreement from the whole
LADSPA community.
Thanks Stefano,
this extra symbol wouldn't be an addition to LADSPA itself. Instead,
it would be one private to caps.so, completely independent of the
plugin standard.
Like so, for example:
void * h = dlopen ("/path/to/caps.so", RTLD_LAZY);
/* assuming h is valid, check for caps */
const int * caps = (const int *) dlsym (h, "__caps_version__");
if (caps)
printf ("found caps version %d.%d.%d", caps[0], caps[1], caps[2]);
Should you consider special-casing for individual plugin libraries a
pragmatic and viable approach, I'd imagine something like this to be
helpful. (Put together, the caps library version and the UniqueID of
a plugin guarantee a stable port signature.)
3:16 p.m.
2011/4/5 David Robillard <d(a)drobilla.net>et>:
On 03/04/11 04:34 AM, Stefano D'Angelo wrote:
Tim, you see? David already suggests to use the LADSPA prefix. :-)
However, I think you could happily avoid doing anything special, I can
check if the plugin in question (identified by UniqueID) has more
ports than the current version (this has to be hardcoded into the
bridge), thus making all ports with index >= the old PortCount
connectionOptional in LV2 (that means the bridge makes fake
connections unless the LV2 host does really connect them)... however,
this is possible if you append the new port(s) to the current ones as
Dave suggests, otherwise this just can't be handled even in LADSPA
hosts properly, I suspect.
Stefano
2011/4/2 Tim Goetze<tim(a)quitte.de>de>:
Global identifiers beginning with __ are reserved for the C
implementation...
Might as well just use LADSPA as a prefix instead of CAPS, in case this
needs doing somewhere else... though this whole thing is extremely awful,
and I really hope that is not the case...
Another less awful option would be to somehow add the information to the
library that the port is connectionOptional...
[Stefano D'Angelo]
Ok, it seems like this is the best way to do it after all... in the
hope that this does not become a trend among LADSPA plugin authors.
Best regards,
Stefano
P.S.: using two version numbers instead of three could be of help in my
case...
2011/3/29 Tim Goetze<tim(a)quitte.de>de>:
>
> It is very unfortunate that such a change might break the way your
> bridge code works, Stefano, and I would like to apologise in advance.
> (If the addition of a 'version' symbol exported by caps.so is any
> help, I'll be happy to add that.)
>
[...]
Regarding the addition of a symbol, introducing something into LADSPA
(because if we agree on something, it's probably going to become a
generic mechanism in the end) is really something I would avoid. It
kind of both defeats the purpose of doing bridging well (i.e., no need
to make changes to existing stuff) and also it would be unfair to
recommend an addition to LADSPA without agreement from the whole
LADSPA community.
Thanks Stefano,
this extra symbol wouldn't be an addition to LADSPA itself. Instead,
it would be one private to caps.so, completely independent of the
plugin standard.
Like so, for example:
void * h = dlopen ("/path/to/caps.so", RTLD_LAZY);
/* assuming h is valid, check for caps */
const int * caps = (const int *) dlsym (h, "__caps_version__");
if (caps)
printf ("found caps version %d.%d.%d", caps[0], caps[1], caps[2]);
Should you consider special-casing for individual plugin libraries a
pragmatic and viable approach, I'd imagine something like this to be
helpful. (Put together, the caps library version and the UniqueID of
a plugin guarantee a stable port signature.)
7 Apr
7 Apr
6:51 p.m.
[Stefano D'Angelo]
And I have to concur, a standardised way for hosts to query the
version of a plugin library seems a good idea indeed.
2011/4/5 David Robillard <d(a)drobilla.net>et>:
> On 03/04/11 04:34 AM, Stefano D'Angelo wrote:
>>
>> 2011/4/2 Tim Goetze<tim(a)quitte.de>de>:
>>> const int * caps = (const int *) dlsym (h, "__caps_version__");
[...]
> Global identifiers beginning with __ are reserved
for the C
> implementation...
Thanks for pointing that out, David, I'll change the symbol to a plain
and simple "CAPS_version" instead.
Might as well
just use LADSPA as a prefix instead of CAPS, in case this
needs doing somewhere else... though this whole thing is extremely awful,
and I really hope that is not the case...
Another less awful option would be to somehow add the information to the
library that the port is connectionOptional...
Tim, you see? David already suggests to use the LADSPA prefix. :-) However, I think you could happily avoid doing anything
special, I can
check if the plugin in question (identified by UniqueID) has more
ports than the current version (this has to be hardcoded into the
bridge), thus making all ports with index >= the old PortCount
connectionOptional in LV2 (that means the bridge makes fake
connections unless the LV2 host does really connect them)... however,
this is possible if you append the new port(s) to the current ones as
Dave suggests, otherwise this just can't be handled even in LADSPA
hosts properly, I suspect.
The new port for the AutoWah plugin will indeed be appended to the
list of input ports; however, it will still precede the audio output,
adhering to the CAPS port order convention which puts inputs before
outputs.
(I'm afraid you'll have to make slight changes to the above algorithm
to make it work in this case, but at first glance it seems you only
need to apply the same method to in- and outputs separately. And I'd
like to apologise again for the trouble caused.)
Cheers, Tim
8 Apr
8 Apr
2:53 a.m.
On 07/04/11 01:00 PM, Tim Goetze wrote:
And I have to concur, a standardised way for hosts to query the
version of a plugin library seems a good idea indeed.
Well, yes and no. Since LADSPA can not tolerate plugin breakage at all,
one could argue that the presence of such a thing is a symptom...
This will horribly break all sorts of things. Do not do this!
Admittedly, slightly less so than rearranging control port indices would
(which would definitely break virtually everything), but still.
You should just change the ID of the plugin and this whole mess goes
away. I can't think of any reason to keep the ID and break the plugin
rather than just change the ID...
Cheers,
-dr
[Stefano D'Angelo]
You're welcome.
2011/4/5 David Robillard<d(a)drobilla.net>et>:
> On 03/04/11 04:34 AM, Stefano D'Angelo wrote:
>
>> 2011/4/2 Tim Goetze<tim(a)quitte.de>de>:
>>
>>> �const int * caps = (const int *) dlsym (h, "__caps_version__");
>>>
[...]
> Global identifiers beginning with __ are
reserved for the C
> implementation...
>
Thanks for pointing that out, David, I'll change the symbol to a
plain
and simple "CAPS_version" instead.
Might as well just use LADSPA as a prefix instead of
CAPS, in case this
needs doing somewhere else... though this whole thing is extremely awful,
and I really hope that is not the case...
Another less awful option would be to somehow add the information to the
library that the port is connectionOptional...
Tim, you see? David already suggests to use the LADSPA prefix. :-)
However, I
think you could happily avoid doing anything special, I can
check if the plugin in question (identified by UniqueID) has more
ports than the current version (this has to be hardcoded into the
bridge), thus making all ports with index>= the old PortCount
connectionOptional in LV2 (that means the bridge makes fake
connections unless the LV2 host does really connect them)... however,
this is possible if you append the new port(s) to the current ones as
Dave suggests, otherwise this just can't be handled even in LADSPA
hosts properly, I suspect.
The new port for the AutoWah plugin will indeed be appended to the
list of input ports; however, it will still precede the audio output,
adhering to the CAPS port order convention which puts inputs before
outputs.
3:32 a.m.
On Thu, Apr 7, 2011 at 8:53 PM, David Robillard <d(a)drobilla.net> wrote:
You should just change the ID of the plugin and this
whole mess goes away. I
can't think of any reason to keep the ID and break the plugin rather than
just change the ID...
And name it AutoFilter...like the Maxon AF-9 Auto Filter...
10 Apr
10 Apr
9:43 a.m.
[David Robillard]
On 07/04/11 01:00 PM, Tim Goetze wrote:
I'm afraid you generously overestimate the popularity of CAPS and the
AutoWah plugin in particular expecting this change to break "all sorts
of things". And you seem to underestimate the ability of your fellow
host application designers, as we shall see in a bit.
The new port for the AutoWah plugin will indeed
be appended to the
list of input ports; however, it will still precede the audio output,
adhering to the CAPS port order convention which puts inputs before
outputs.
This will horribly break all sorts of things. Do not do this! Admittedly,
slightly less so than rearranging control port indices would (which would
definitely break virtually everything), but still. You should just change the ID of the plugin and this
whole mess goes away. I
can't think of any reason to keep the ID and break the plugin rather than just
change the ID...
Adding a port doesn't break the *plugin*, it /might/ break *hosts*
that were designed around assumptions that aren't supported by the
interface specification.
An informal experiment shows that jack-rack 1.4.7 and ardour 2.8.11
both do exactly the right thing when a plugin referenced by a saved
session gains a port: they set the new port to its default value and
happily carry on working.
(Both also cope with the removal of a port. These are the only
publicly available hosts I have tested.)
Following your suggestion and changing the plugin's UniqueID would
break perfectly good saved session files in these and other properly
designed host applications - instead of *preventing* breakage, it'd
actually *cause* it.
If your particular LADSPA host design is incapable of handling a port
signature change gracefully, you could fix it - an endeavour I'll be
happy to help with, witness the discussed version symbol export - or
you can simply choose not to upgrade your copy of CAPS.
[Paul Coccoli]
And name it AutoFilter...like the Maxon AF-9 Auto
Filter...
Yeah, with the added filter mode switch this name makes sense.
Looking at the AF-9 it seems there's demand for a hi-pass mode as
well, so we might as well add that too.
Cheers, Tim
1:33 p.m.
On Sun, Apr 10, 2011 at 3:43 AM, Tim Goetze <tim(a)quitte.de> wrote:
Adding a port doesn't break the *plugin*, it
/might/ break *hosts*
that were designed around assumptions that aren't supported by the
interface specification.
Strongly disagree. There are ways to add a port that won't do this,
but there are plenty of ways to do it that will.
Following your suggestion and changing the
plugin's UniqueID would
break perfectly good saved session files in these and other properly
designed host applications - instead of *preventing* breakage, it'd
actually *cause* it.
Strongly disagree. The CAPS package would just continue to include the
old version of the plugin.
If your particular LADSPA host design is incapable of
handling a port
signature change gracefully, you could fix it - an endeavour I'll be
happy to help with, witness the discussed version symbol export - or
you can simply choose not to upgrade your copy of CAPS.
You can't fix this in Ardour in general. As noted, just appending a
port won't break anything (I think), but the general issue that the
port signature has changed and this invalidates old state for the
plugin is something that definitely goes against everything that we
had in mind when LADSPA was designed.
3:52 p.m.
[Paul Davis]
On Sun, Apr 10, 2011 at 3:43 AM, Tim Goetze
<tim(a)quitte.de> wrote:
Surely you will understand that I'm not inclined to maintain two
versions of a plugin whose code differs in only one line.
However, as a compromise, I am thinking about moving obsolete plugins
into a separate 'abandoned' package that would not enjoy further
maintenance. It's far from an ideal solution but then again nothing
seems to be.
Following your suggestion and changing the
plugin's UniqueID would
break perfectly good saved session files in these and other properly
designed host applications - instead of *preventing* breakage, it'd
actually *cause* it.
Strongly disagree. The CAPS package would just continue to include the
old version of the plugin. You can't fix this in Ardour in general. As noted,
just appending a
port won't break anything (I think), but the general issue that the
port signature has changed and this invalidates old state for the
plugin is something that definitely goes against everything that we
had in mind when LADSPA was designed.
In that case, it is rather unfortunate that the specification bears
not a trace of your thoughts on this matter.
Perhaps you want to make an effort to fix it?
Cheers, Tim
6:51 p.m.
On Apr 10, 2011, at 3:52 PM, Tim Goetze wrote:
[Paul Davis]
That sounds like a good case of an #ifdef, no?
Just generate two plugins from the same code: old one: unchanged; updated version: new
UniqueID.
just an idea..
robin
On Sun, Apr 10, 2011 at 3:43 AM, Tim Goetze
<tim(a)quitte.de> wrote:
Surely you will understand that I'm not inclined to maintain two
versions of a plugin whose code differs in only one line.
Following your suggestion and changing the
plugin's UniqueID would
break perfectly good saved session files in these and other properly
designed host applications - instead of *preventing* breakage, it'd
actually *cause* it.
Strongly disagree. The CAPS package would just continue to include the
old version of the plugin.
8:15 p.m.
[Robin Gareus]
On Apr 10, 2011, at 3:52 PM, Tim Goetze wrote:
Thanks Robin, while this is of course entirely viable and not
unreasonable, unfortunately I see two problems: besides the code,
there are also differences in the data describing the plugin that
would need to be put inside conditionals, and that is not as handily
concentrated into one line as is the case with the code.
And to be quite honest, smart adhoc solutions like these create
exactly the kind of source code that I don't want to have to maintain.
:D
Cheers, Tim
Surely you will understand that I'm not inclined to maintain two
versions of a plugin whose code differs in only one line.
That sounds like a good case of an #ifdef, no? Just generate two
plugins from the same code: old one: unchanged; updated version: new
UniqueID.
30 Mar
30 Mar
4:51 a.m.
On 29/03/11 02:59 PM, Tim Goetze wrote:
[Philipp �berbacher]
/Adding/ a port is probably fine, since hosts can just use the default
value or connect it to silence.
However, "adding" here really means "appending": the new ports must be
added on to the end of the ports (by index). Definitely do NOT change
existing indices for ports, that will definitely break a lot of things
in horrible ways! It's not even possible to properly cope with that
situation.
Cheers,
-dr
Excerpts from Stefano D'Angelo's message
of 2011-03-28 22:59:46 +0200:
Lacking sufficient knowledge of all the LADSPA hosts out there, I'm
unable to judge how many will cope with the addition of a port to an
existing plugin and how many will not.
This means, if you change the port signature and
maintain the same
UniqueID, we would have incompatibilities in the LV2 world. If you
create a new plugin or don't touch ports, instead, everything's fine.
Stefano
I'd say you'd even have incompatibilities in LADSPA world. Even
fixes in
LADSPA plugins would sometimes need a new ID (This was discussed a while
ago regarding a LADSPA that has an unintuitive port order).
1:40 p.m.
2011/3/30 David Robillard <d(a)drobilla.net>et>:
On 29/03/11 02:59 PM, Tim Goetze wrote:
Mmm.. so I could maybe add the port number to the URI and add
dc:replaces, like this:
<urn:ladspa:1234:5> a lv2:Plugin ; dc:replaces <urn:ladspa:1234> .
Yet, I should send patches to those plugin authors providing both LV2
and LADSPA versions of their plugins (the same holds true for DSSI, I
guess).
At the moment I don't seem to be able to come up with a better solution. :-S
Stefano
[Philipp �berbacher]
/Adding/ a port is probably fine, since hosts can just use the default value
or connect it to silence.
However, "adding" here really means "appending": the new ports must
be added
on to the end of the ports (by index). Definitely do NOT change existing
indices for ports, that will definitely break a lot of things in horrible
ways! It's not even possible to properly cope with that situation.
Excerpts from Stefano D'Angelo's message of 2011-03-28 22:59:46 +0200:
Lacking sufficient knowledge of all the LADSPA hosts out there, I'm
unable to judge how many will cope with the addition of a port to an
existing plugin and how many will not.
This means, if you change the port signature and maintain the same
UniqueID, we would have incompatibilities in the LV2 world. If you
create a new plugin or don't touch ports, instead, everything's fine.
Stefano
I'd say you'd even have incompatibilities in LADSPA world. Even fixes in
LADSPA plugins would sometimes need a new ID (This was discussed a while
ago regarding a LADSPA that has an unintuitive port order).
1 Apr
1 Apr
8:15 p.m.
On 30/03/11 07:40 AM, Stefano D'Angelo wrote:
2011/3/30 David Robillard<d(a)drobilla.net>et>:
You could to this, but the URI is changed, and that URI doesn't adhere
to the standard LADSPA URI scheme (don't do that).
On 29/03/11 02:59 PM, Tim Goetze wrote:
Mmm.. so I could maybe add the port number to the URI and add
dc:replaces, like this:
<urn:ladspa:1234:5> a lv2:Plugin ; dc:replaces<urn:ladspa:1234> .
[Philipp �berbacher]
/Adding/ a port is probably fine, since hosts can just use the default
value
or connect it to silence.
However, "adding" here really means "appending": the new ports must
be added
on to the end of the ports (by index). Definitely do NOT change existing
indices for ports, that will definitely break a lot of things in horrible
ways! It's not even possible to properly cope with that situation.
Excerpts from Stefano D'Angelo's message
of 2011-03-28 22:59:46 +0200:
> This means, if you change the port signature and maintain the same
> UniqueID, we would have incompatibilities in the LV2 world. If you
> create a new plugin or don't touch ports, instead, everything's fine.
>
> Stefano
>
>
I'd say you'd even have incompatibilities in LADSPA world. Even fixes in
LADSPA plugins would sometimes need a new ID (This was discussed a while
ago regarding a LADSPA that has an unintuitive port order).
Lacking sufficient knowledge of all the LADSPA hosts out there, I'm
unable to judge how many will cope with the addition of a port to an
existing plugin and how many will not.
Yet, I should send patches to those plugin authors
providing both LV2
and LADSPA versions of their plugins (the same holds true for DSSI, I
guess).
At the moment I don't seem to be able to come up with a better solution. :-S
In LV2, the way to do this correctly is to add a connectionOptional
port, and the URI does not have to change. You would have to special
case this, I suppose.
We could also just port CAPS :)
-dr
30 Mar
30 Mar
3:04 p.m.
On 03/28/2011 11:27 PM, Philipp Überbacher wrote:
Excerpts from Stefano D'Angelo's message of
2011-03-28 22:59:46 +0200:
Sorry guys but I don't follow you here. Can't you add or remove ports to an
existing plugin in a new release? Does LV2 considers that two plugins with the
same URI but different ports are actually different plugins? As for two C++
functions with the same name but different arguments?
--
Olivier
2011/3/28 Tim Goetze <tim(a)quitte.de>de>:
Heh... long story
short: LV2 uses URIs, LADSPA uses UniqueIDs (not
necessarily but...), two LV2 plugins with same URI are required to
have the same "port signature" (i.e., ports) and I wrote a LADSPA to
LV2 bridge where the URIs of the bridged plugins are in the form
urn:ladspa:xxxx, where xxxx is the UniqueID.
This means, if you change the port signature and maintain the same
UniqueID, we would have incompatibilities in the LV2 world. If you
create a new plugin or don't touch ports, instead, everything's fine.
Stefano
I'd say you'd even have incompatibilities in LADSPA world. Even fixes in
LADSPA plugins would sometimes need a new ID (This was discussed a while
ago regarding a LADSPA that has an unintuitive port order). >
I'm planning to add a mode switch (low- or bandpass) to the AutoWah
> instead of making a separate new plugin, or would that be a stupid
> idea?
For compatibility with LV2, it's better if you create a new plugin for that...
I don't see how compatibility with LV2 is a concern here? 
3:15 p.m.
From the docs for LV2_Descriptor::URI:
A globally unique, case-sensitive identifier for this plugin type.
All plugins with the same URI MUST be compatible in terms of 'port
signature', meaning they have the same number of ports, same port
shortnames, and roughly the same functionality. URIs should probably
contain a version number (or similar) for this reason.
Rationale: When serializing session/patch/etc files, hosts MUST refer
to a loaded plugin by the plugin URI only. In the future loading a
plugin with this URI MUST yield a plugin with the same ports (etc)
which is 100% compatible.
--Paul
On Tue, Mar 29, 2011 at 1:17 PM, Olivier Guilyardi <list(a)samalyse.com> wrote:
On 03/28/2011 11:27 PM, Philipp Überbacher wrote:
Excerpts from Stefano D'Angelo's message
of 2011-03-28 22:59:46 +0200:
Sorry guys but I don't follow you here. Can't you add or remove ports to an
existing plugin in a new release? Does LV2 considers that two plugins with the
same URI but different ports are actually different plugins? As for two C++
functions with the same name but different arguments?
--
Olivier
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
2011/3/28 Tim Goetze <tim(a)quitte.de>de>:
I'd say you'd even have incompatibilities in LADSPA world. Even fixes in
LADSPA plugins would sometimes need a new ID (This was discussed a while
ago regarding a LADSPA that has an unintuitive port order). >> I'm planning to add a mode switch
(low- or bandpass) to the AutoWah
>> instead of making a separate new plugin, or would that be a stupid
>> idea?
> For compatibility with LV2, it's better if you create a new plugin for that...
I don't see how compatibility with LV2 is a concern here?
Heh... long story
short: LV2 uses URIs, LADSPA uses UniqueIDs (not
necessarily but...), two LV2 plugins with same URI are required to
have the same "port signature" (i.e., ports) and I wrote a LADSPA to
LV2 bridge where the URIs of the bridged plugins are in the form
urn:ladspa:xxxx, where xxxx is the UniqueID.
This means, if you change the port signature and maintain the same
UniqueID, we would have incompatibilities in the LV2 world. If you
create a new plugin or don't touch ports, instead, everything's fine.
Stefano
1 Apr
1 Apr
8:18 p.m.
On 30/03/11 09:15 AM, Paul Giblock wrote:
From the docs for LV2_Descriptor::URI:
A globally unique, case-sensitive identifier for this plugin type.
All plugins with the same URI MUST be compatible in terms of 'port
signature', meaning they have the same number of ports, same port
shortnames, and roughly the same functionality. URIs should probably
contain a version number (or similar) for this reason.
Rationale: When serializing session/patch/etc files, hosts MUST refer
to a loaded plugin by the plugin URI only. In the future loading a
plugin with this URI MUST yield a plugin with the same ports (etc)
which is 100% compatible.
--Paul
Please refer to LV2 4.0[1] for anything related to this (compatibility,
versioning, etc.). One of the main improvements in that release was very
solidly defining this.
-dr
http://lv2plug.in/ns/lv2core
P.S. Please do not top post on mailing lists...
4778
days inactive
4793
days old
linux-audio-dev@lists.linuxaudio.org
28 comments
11 participants
participants (11)
-
David Robillard -
Jostein Chr. Andersen -
Julien Claassen -
Olivier Guilyardi -
Paul Coccoli -
Paul Davis -
Paul Giblock -
Philipp Überbacher -
Robin Gareus -
Stefano D'Angelo -
Tim Goetze