Re: [LAD] [ann] CAPS 0.4.5
On 18 April 2011 15:50, David Robillard d...@drobilla.net wrote: On Sun, 2011-04-17 at 19:16 +0100, Chris Cannam wrote: Library name plus label, for example. That is not guaranteed to be unique, and I know of at least one case in practise where it isn't (various blop packages have a different library name). There's no reason whatsoever the library name and label of various LADSPA plugin distributions can't be completely different, neither one is an ID. Indeed, but at least the typical failure case (when the library name differs from the expected one) is that the plugin isn't loaded and the program can report it, rather than that the wrong plugin is loaded silently as occurs with the numerical ID. Perhaps the LADSPA spec /should/ use that (or whatever else) as an identifier, but it doesn't. As Stefano pointed out, it does in fact say plugin types should be identified by file and label. I admit the text is strange given the presence of the ID as well. file name + label would be a really annoying two-piece identifier anyway, even if it was an actual global identifer. So make a pseudo URI or something out of it. Anyway, the situation is a bit unsatisfactory either way and I don't think we disagree on that -- probably not much point in arguing about the details these days. A proper URI is a better option in any circumstance. Chris ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ann] CAPS 0.4.5
On Sun, 2011-04-17 at 19:16 +0100, Chris Cannam wrote: On 17 April 2011 18:12, David Robillard d...@drobilla.net wrote: On Thu, 2011-04-14 at 11:59 +0100, Chris Cannam wrote: I like to disagree with David on most things LADSPA -- for example I think a host that uses the unique ID at all is broken from the outset Well, that's just silly... it's the only ID there is. What else would they use? Library name plus label, for example. My hosts do that and have done for years. Not ideal either of course, but at least it doesn't completely stuff up any situation where a numerical ID can't be generated in advance (dssi-vst, etc). That is not guaranteed to be unique, and I know of at least one case in practise where it isn't (various blop packages have a different library name). There's no reason whatsoever the library name and label of various LADSPA plugin distributions can't be completely different, neither one is an ID. Of course, the numeric IDs are screwed up for a few plugins in reality as well, but at least that is actually defined to be an ID (therefore those plugins are broken). Perhaps the LADSPA spec /should/ use that (or whatever else) as an identifier, but it doesn't. It is an extremely bad idea to pretend a spec says what you wish it did and implement that instead of what the spec actually says. I know because I blindly heeded this advice in the past, and it screwed me :). Please don't advise people that this is what a LADSPA implementation should do... -dr ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ann] CAPS 0.4.5
2011/4/18 David Robillard d...@drobilla.net: On Sun, 2011-04-17 at 19:16 +0100, Chris Cannam wrote: On 17 April 2011 18:12, David Robillard d...@drobilla.net wrote: On Thu, 2011-04-14 at 11:59 +0100, Chris Cannam wrote: I like to disagree with David on most things LADSPA -- for example I think a host that uses the unique ID at all is broken from the outset Well, that's just silly... it's the only ID there is. What else would they use? Library name plus label, for example. My hosts do that and have done for years. Not ideal either of course, but at least it doesn't completely stuff up any situation where a numerical ID can't be generated in advance (dssi-vst, etc). That is not guaranteed to be unique, and I know of at least one case in practise where it isn't (various blop packages have a different library name). There's no reason whatsoever the library name and label of various LADSPA plugin distributions can't be completely different, neither one is an ID. Of course, the numeric IDs are screwed up for a few plugins in reality as well, but at least that is actually defined to be an ID (therefore those plugins are broken). Perhaps the LADSPA spec /should/ use that (or whatever else) as an identifier, but it doesn't. It is an extremely bad idea to pretend a spec says what you wish it did and implement that instead of what the spec actually says. I know because I blindly heeded this advice in the past, and it screwed me :). Please don't advise people that this is what a LADSPA implementation should do... /* This identifier can be used as a unique, case-sensitive identifier for the plugin type within the plugin file. Plugin types should be identified by file and label rather than by index or plugin name, which may be changed in new plugin versions. Labels must not contain white-space characters. */ const char * Label; I would say Chris is right here... but since I don't care about LADSPA hosts, and only about LADSPA plugins bridged to LV2, for our purposes UniqueID is fine (bridging bridged plugins is not of interest to me). Hence I would say, LADSPA hosts: use filename/label, LV2 URIs for LADSPA plugins are fine with UniqueID only. Stefano ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ann] CAPS 0.4.5
On Mon, 2011-04-18 at 17:09 +0200, Stefano D'Angelo wrote: 2011/4/18 David Robillard d...@drobilla.net: On Sun, 2011-04-17 at 19:16 +0100, Chris Cannam wrote: On 17 April 2011 18:12, David Robillard d...@drobilla.net wrote: On Thu, 2011-04-14 at 11:59 +0100, Chris Cannam wrote: I like to disagree with David on most things LADSPA -- for example I think a host that uses the unique ID at all is broken from the outset Well, that's just silly... it's the only ID there is. What else would they use? Library name plus label, for example. My hosts do that and have done for years. Not ideal either of course, but at least it doesn't completely stuff up any situation where a numerical ID can't be generated in advance (dssi-vst, etc). That is not guaranteed to be unique, and I know of at least one case in practise where it isn't (various blop packages have a different library name). There's no reason whatsoever the library name and label of various LADSPA plugin distributions can't be completely different, neither one is an ID. Of course, the numeric IDs are screwed up for a few plugins in reality as well, but at least that is actually defined to be an ID (therefore those plugins are broken). Perhaps the LADSPA spec /should/ use that (or whatever else) as an identifier, but it doesn't. It is an extremely bad idea to pretend a spec says what you wish it did and implement that instead of what the spec actually says. I know because I blindly heeded this advice in the past, and it screwed me :). Please don't advise people that this is what a LADSPA implementation should do... /* This identifier can be used as a unique, case-sensitive identifier for the plugin type within the plugin file. Plugin types should be identified by file and label rather than by index or plugin name, which may be changed in new plugin versions. Labels must not contain white-space characters. */ const char * Label; I would say Chris is right here... but since I don't care about LADSPA hosts, and only about LADSPA plugins bridged to LV2, for our purposes UniqueID is fine (bridging bridged plugins is not of interest to me). within the plugin file Nothing says the plugin file name is meaningful in any way, or globally unique. Ironically bridges and plugin generators and such, the case mentioned as a rationalization for this, is one case where it wouldn't be. file name + label would be a really annoying two-piece identifier anyway, even if it was an actual global identifer. The LADSPA spec is pretty broken in this respect, if that pair of quasi identifiers is the global identifier then why would there be a UniqueID in the first place? -dr ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ann] CAPS 0.4.5
On Thu, 2011-04-14 at 11:59 +0100, Chris Cannam wrote: [...] I like to disagree with David on most things LADSPA -- for example I think a host that uses the unique ID at all is broken from the outset [...] Well, that's just silly... it's the only ID there is. What else would they use? -dr ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ann] CAPS 0.4.5
On 17 April 2011 18:12, David Robillard d...@drobilla.net wrote: On Thu, 2011-04-14 at 11:59 +0100, Chris Cannam wrote: I like to disagree with David on most things LADSPA -- for example I think a host that uses the unique ID at all is broken from the outset Well, that's just silly... it's the only ID there is. What else would they use? Library name plus label, for example. My hosts do that and have done for years. Not ideal either of course, but at least it doesn't completely stuff up any situation where a numerical ID can't be generated in advance (dssi-vst, etc). Chris ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ann] CAPS 0.4.5
On 13 April 2011 22:03, Tim E. Real termt...@rogers.com wrote: I agree that if this new port were to be sandwiched among the others or if he were removing ports, that's breakage. I think that was the plan, though -- to put the new port after the other control ports and before any of the existing audio ones. And that's the problem. I like to disagree with David on most things LADSPA -- for example I think a host that uses the unique ID at all is broken from the outset, because there's no way to ensure that ID is actually unique, e.g. for plugin wrappers. But in this case, and even though my own hosts should cope with Tim's change without problems, I have to agree that the change is not a good idea. Chris ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ann] CAPS 0.4.5
On April 14, 2011 06:59:34 am you wrote: On 13 April 2011 22:03, Tim E. Real termt...@rogers.com wrote: I agree that if this new port were to be sandwiched among the others or if he were removing ports, that's breakage. I think that was the plan, though -- to put the new port after the other control ports and before any of the existing audio ones. And that's the problem. Oh I see. Not good. But doesn't audio come before controls? I was in our code the other day and IIRC noticed audio came before controls. (That's why I posted.) Or is that simply how port ordering is /presented/ to me from LADSPA? Hypothetically, if the new port really did come after ALL others, would that still break anything, including that LV2 bridge? If MusE found some control ports followed by audio ports followed by more control ports, it would still cope fine. Thanks for the enlightenment. I'm learning (l)rdf and LV2 stuff now, with an eye towards LV2 support. (I only recently learned what the 'L' stands for. Now it all makes sense - it's LADSPA all grown up.) Tim E. I like to disagree with David on most things LADSPA -- for example I think a host that uses the unique ID at all is broken from the outset, because there's no way to ensure that ID is actually unique, e.g. for plugin wrappers. But in this case, and even though my own hosts should cope with Tim's change without problems, I have to agree that the change is not a good idea. Chris ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ann] CAPS 0.4.5
On 12/04/11 06:00 AM, Tim Goetze wrote: [David Robillard] No, the pragmatic thing to do is not deliberately break your plugin when several knowledgeable people have pointed out that doing so can cause countless problems. Again: not the plugin is broken, but the host that assumes the port signature not to change over different plugin versions. No, a given index on your plugin no longer refers to the same port, therefore the interface to the plugin has been broken, period. There is no mention of such a requirement in the interface specification, therefore the assumption is invalid and the responsibility for potential breakage lies with the host. This assumption is obvious, since indices are the ID for a port. To argue that this is not true is literally equivalent to arguing that LADSPA does not support saving session/patch/etc files in any way, at all, whatsoever, since indices are meaningless and can not be relied upon to refer to the same port when the plugin is reloaded later. Obviously this is absurd. Your assumption, that hosts must refer to ports by an index within a special separate index namespace for control and audio ports, is a much greater one: it is not obvious, and the alternative is not absurd. It is, in other words, clearly not in the language or spirit of LADSPA. There is no reason someone reading ladspa.h and writing an implementation would reasonably come to the conclusion that this is the required correct behavior. It has been shown that properly designed hosts handle the port addition just fine. This is just conveniently, but erroneously, redefining properly designed hosts to mean hosts that won't break when I break my plugin in this particular way. You may of course argue - not entirely unreasonably - that it is more pragmatic for the plugin author to cater for broken hosts than to expect them to be fixed. Do you? No, because the host is not broken, as myself and others (including one of the main authors of LADSPA itself, and the main author of the host in question) have explained several times over. You are trying to argue that LADSPA does not present this assumption that indices refer to a constant port, but as mentioned above, this is an obvious conclusion, since the alternative is absurd (ports clearly must have /some/ ID). LADSPA certainly does not specify the more complex definition of correct use of port indices that you are trying to justify (nor should it, for several reasons, but that is beside the point). The simplest, most obvious, and intended rule is: If a given port index does not refer to the same port on a new version of a plugin, then the plugin interface has broken and the plugin ID MUST be changed. As Fons mentioned, this is effectively a different plugin. Your definition, which splits the port index namespace into two separate namespaces, one for control and one for audio, is not obviously intended and is not mentioned or alluded to anywhere in LADSPA whatsoever. Hosts that do not do this are not broken. That every single host author who has participated in this thread agrees, and the fact that you need to add a version number so one can kludge around the broken plugin, makes that pretty clear... Cheers, -dr P.S. I do empathize with the fact that changing IDs where it /could/ not be necessary sucks; this is why LV2 has symbols which are the ID for a port instead. However, LADSPA is LADSPA, and doing what you are proposing is going to cause real headaches for real people, and would be remarkably unskillful given the feedback in this thread... please just don't do it :) ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ann] CAPS 0.4.5
On April 13, 2011 02:11:02 pm David Robillard wrote: On 12/04/11 06:00 AM, Tim Goetze wrote: [David Robillard] No, the pragmatic thing to do is not deliberately break your plugin when several knowledgeable people have pointed out that doing so can cause countless problems. Again: not the plugin is broken, but the host that assumes the port signature not to change over different plugin versions. No, a given index on your plugin no longer refers to the same port, therefore the interface to the plugin has been broken, period. But he only wants to add a new port, not change them around or remove them, doesn't he? So the indexes are not changing. So long as this new port comes after all the others, including audio, what's the problem? Our MusE can cope, can the others? I agree that if this new port were to be sandwiched among the others or if he were removing ports, that's breakage. How is a plugin supposed to grow and mature? I mean the Caps ToneStack gained a few 'model' values over the years. Did it change unique ID? Every time he wants to add a new port he's got to change the ID? So we end up with ten different versions with ten different IDs? Maybe the others are referring to breaking lrdf (I'm just learning lrdf now). Or if someone tries to load a song referring to the new plugin version, on an older system having the old plugin version. But I know MusE can still handle that, when loading a song it just ignores any port ID out of range of the number of ports. It's a tough decision I know, I empathize, and if the consensus is that the ID should be changed, I guess you gotta do it. But surely we could accept this small change, can't we? I mean what, really, would break? Thanks. Tim E. There is no mention of such a requirement in the interface specification, therefore the assumption is invalid and the responsibility for potential breakage lies with the host. This assumption is obvious, since indices are the ID for a port. To argue that this is not true is literally equivalent to arguing that LADSPA does not support saving session/patch/etc files in any way, at all, whatsoever, since indices are meaningless and can not be relied upon to refer to the same port when the plugin is reloaded later. Obviously this is absurd. Your assumption, that hosts must refer to ports by an index within a special separate index namespace for control and audio ports, is a much greater one: it is not obvious, and the alternative is not absurd. It is, in other words, clearly not in the language or spirit of LADSPA. There is no reason someone reading ladspa.h and writing an implementation would reasonably come to the conclusion that this is the required correct behavior. It has been shown that properly designed hosts handle the port addition just fine. This is just conveniently, but erroneously, redefining properly designed hosts to mean hosts that won't break when I break my plugin in this particular way. You may of course argue - not entirely unreasonably - that it is more pragmatic for the plugin author to cater for broken hosts than to expect them to be fixed. Do you? No, because the host is not broken, as myself and others (including one of the main authors of LADSPA itself, and the main author of the host in question) have explained several times over. You are trying to argue that LADSPA does not present this assumption that indices refer to a constant port, but as mentioned above, this is an obvious conclusion, since the alternative is absurd (ports clearly must have /some/ ID). LADSPA certainly does not specify the more complex definition of correct use of port indices that you are trying to justify (nor should it, for several reasons, but that is beside the point). The simplest, most obvious, and intended rule is: If a given port index does not refer to the same port on a new version of a plugin, then the plugin interface has broken and the plugin ID MUST be changed. As Fons mentioned, this is effectively a different plugin. Your definition, which splits the port index namespace into two separate namespaces, one for control and one for audio, is not obviously intended and is not mentioned or alluded to anywhere in LADSPA whatsoever. Hosts that do not do this are not broken. That every single host author who has participated in this thread agrees, and the fact that you need to add a version number so one can kludge around the broken plugin, makes that pretty clear... Cheers, -dr P.S. I do empathize with the fact that changing IDs where it /could/ not be necessary sucks; this is why LV2 has symbols which are the ID for a port instead. However, LADSPA is LADSPA, and doing what you are proposing is going to cause real headaches for real people, and would be remarkably unskillful given the feedback in this thread... please just don't do it :) ___ Linux-audio-dev mailing list
Re: [LAD] [ann] CAPS 0.4.5
On April 13, 2011 05:03:45 pm you wrote: On April 13, 2011 02:11:02 pm David Robillard wrote: On 12/04/11 06:00 AM, Tim Goetze wrote: [David Robillard] No, the pragmatic thing to do is not deliberately break your plugin when several knowledgeable people have pointed out that doing so can cause countless problems. Again: not the plugin is broken, but the host that assumes the port signature not to change over different plugin versions. No, a given index on your plugin no longer refers to the same port, therefore the interface to the plugin has been broken, period. But he only wants to add a new port, not change them around or remove them, doesn't he? So the indexes are not changing. So long as this new port comes after all the others, including audio, what's the problem? Our MusE can cope, can the others? I agree that if this new port were to be sandwiched among the others or if he were removing ports, that's breakage. How is a plugin supposed to grow and mature? I mean the Caps ToneStack gained a few 'model' values over the years. Did it change unique ID? Every time he wants to add a new port he's got to change the ID? So we end up with ten different versions with ten different IDs? Maybe the others are referring to breaking lrdf (I'm just learning lrdf now). Or if someone tries to load a song referring to the new plugin version, on an older system having the old plugin version. But I know MusE can still handle that, when loading a song it just ignores any port ID out of range of the number of ports. It's a tough decision I know, I empathize, and if the consensus is that the ID should be changed, I guess you gotta do it. But surely we could accept this small change, can't we? I mean what, really, would break? Thanks. Tim E. Ah, just read up the thread terribly sorry. LV2 issues and such plus that bridge. A new plugin would be best. It's OK, we see it in some other plugins, incremental upgrades. I never seemed to notice or mind much, guess I've always assumed that maybe other versions were made by someone else. Tim E. There is no mention of such a requirement in the interface specification, therefore the assumption is invalid and the responsibility for potential breakage lies with the host. This assumption is obvious, since indices are the ID for a port. To argue that this is not true is literally equivalent to arguing that LADSPA does not support saving session/patch/etc files in any way, at all, whatsoever, since indices are meaningless and can not be relied upon to refer to the same port when the plugin is reloaded later. Obviously this is absurd. Your assumption, that hosts must refer to ports by an index within a special separate index namespace for control and audio ports, is a much greater one: it is not obvious, and the alternative is not absurd. It is, in other words, clearly not in the language or spirit of LADSPA. There is no reason someone reading ladspa.h and writing an implementation would reasonably come to the conclusion that this is the required correct behavior. It has been shown that properly designed hosts handle the port addition just fine. This is just conveniently, but erroneously, redefining properly designed hosts to mean hosts that won't break when I break my plugin in this particular way. You may of course argue - not entirely unreasonably - that it is more pragmatic for the plugin author to cater for broken hosts than to expect them to be fixed. Do you? No, because the host is not broken, as myself and others (including one of the main authors of LADSPA itself, and the main author of the host in question) have explained several times over. You are trying to argue that LADSPA does not present this assumption that indices refer to a constant port, but as mentioned above, this is an obvious conclusion, since the alternative is absurd (ports clearly must have /some/ ID). LADSPA certainly does not specify the more complex definition of correct use of port indices that you are trying to justify (nor should it, for several reasons, but that is beside the point). The simplest, most obvious, and intended rule is: If a given port index does not refer to the same port on a new version of a plugin, then the plugin interface has broken and the plugin ID MUST be changed. As Fons mentioned, this is effectively a different plugin. Your definition, which splits the port index namespace into two separate namespaces, one for control and one for audio, is not obviously intended and is not mentioned or alluded to anywhere in LADSPA whatsoever. Hosts that do not do this are not broken. That every single host author who has participated in this thread agrees, and the fact that you need to add a version number so one can kludge around the broken plugin, makes that pretty clear... Cheers, -dr P.S. I do
Re: [LAD] [ann] CAPS 0.4.5
On 10/04/11 06:21 PM, Tim Goetze wrote: [Jeff McClintock] What happens when you modify version-1 of your plugin and remove a port (making Version2), then later re-add a new (unrelated) port with different semantics? (Version 3)... Then load a project created with version 1. Does the host in THIS situation set the new port to it's default value, I doubt it. More likely it 'restores' it to some invalid setting. Do you want a fragile, crash-prone, plugin ecosystem?, or a robust one? The plugins in CAPS clamp all control inputs to the valid range. Whatever the host sends, including inf and nan, there is no invalid setting. Moreover, the plugins will not crash even if run without connecting their control ports at all. The above experiment, by the way, is exactly what I did, and it did not cause any abnormal behaviour: no crash, no segfault, no bus error, no assertion failure in any part of the executed code; no inf or nan, not even a single sample value of or in excess of 1f absolute in the audio output. I think your fear of a fragile and crash-prone plugin ecosystem is unfounded and exaggerated. I Agree with Paul on this one. I can very well see how a host author would want plugin port signatures to be stable, and I was never happy about invalidating this assumption. However, the evolved plugin doesn't even break ardour or its session files, so the pragmatic thing is to just get on with it and not waste as much breath on a triviality like this as we do now. No, the pragmatic thing to do is not deliberately break your plugin when several knowledgeable people have pointed out that doing so can cause countless problems. One test with one version of one host certainly does not outweigh that.. particularly when one of said knowledgeable people is the primary author of that host! -dr ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ann] CAPS 0.4.5
On Mon, Apr 11, 2011 at 12:21:31AM +0200, Tim Goetze wrote: I can very well see how a host author would want plugin port signatures to be stable, and I was never happy about invalidating this assumption. However, the evolved plugin doesn't even break ardour or its session files, so the pragmatic thing is to just get on with it and not waste as much breath on a triviality like this as we do now. Shouldn't such situations be avoided by 1. Giving the new plugin version a new unique ID so it can't be mistaken for the old one (and vice versa) and 2. Making sure that installing the new version does not remove or hide the old one. Since the new version is not a bugfix for the old one but actually something different this seems to be the logical thing to do. That way any existing sessions will just go on use the version they knew. It's then up to the user to update his/her session (or not). Ciao, -- FA ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ann] CAPS 0.4.5
[David Robillard] On 07/04/11 01:00 PM, Tim Goetze wrote: 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. 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. 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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ann] CAPS 0.4.5
On Sun, Apr 10, 2011 at 3:43 AM, Tim Goetze t...@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. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ann] CAPS 0.4.5
[Paul Davis] On Sun, Apr 10, 2011 at 3:43 AM, Tim Goetze t...@quitte.de wrote: 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. 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. 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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ann] CAPS 0.4.5
On Apr 10, 2011, at 3:52 PM, Tim Goetze wrote: [Paul Davis] On Sun, Apr 10, 2011 at 3:43 AM, Tim Goetze t...@quitte.de wrote: 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. 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. just an idea.. robin ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ann] CAPS 0.4.5
[Robin Gareus] On Apr 10, 2011, at 3:52 PM, Tim Goetze wrote: 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. 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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ann] CAPS 0.4.5
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.) What happens when you modify version-1 of your plugin and remove a port (making Version2), then later re-add a new (unrelated) port with different semantics? (Version 3)... Then load a project created with version 1. Does the host in THIS situation set the new port to it's default value, I doubt it. More likely it 'restores' it to some invalid setting. Do you want a fragile, crash-prone, plugin ecosystem?, or a robust one? I Agree with Paul on this one. Best Regards, Jeff ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ann] CAPS 0.4.5
[Jeff McClintock] What happens when you modify version-1 of your plugin and remove a port (making Version2), then later re-add a new (unrelated) port with different semantics? (Version 3)... Then load a project created with version 1. Does the host in THIS situation set the new port to it's default value, I doubt it. More likely it 'restores' it to some invalid setting. Do you want a fragile, crash-prone, plugin ecosystem?, or a robust one? The plugins in CAPS clamp all control inputs to the valid range. Whatever the host sends, including inf and nan, there is no invalid setting. Moreover, the plugins will not crash even if run without connecting their control ports at all. The above experiment, by the way, is exactly what I did, and it did not cause any abnormal behaviour: no crash, no segfault, no bus error, no assertion failure in any part of the executed code; no inf or nan, not even a single sample value of or in excess of 1f absolute in the audio output. I think your fear of a fragile and crash-prone plugin ecosystem is unfounded and exaggerated. I Agree with Paul on this one. I can very well see how a host author would want plugin port signatures to be stable, and I was never happy about invalidating this assumption. However, the evolved plugin doesn't even break ardour or its session files, so the pragmatic thing is to just get on with it and not waste as much breath on a triviality like this as we do now. Cheers, Tim ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ann] CAPS 0.4.5
[Stefano D'Angelo] 2011/4/5 David Robillard d...@drobilla.net: On 03/04/11 04:34 AM, Stefano D'Angelo wrote: 2011/4/2 Tim Goetzet...@quitte.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. :-) And I have to concur, a standardised way for hosts to query the version of a plugin library seems a good idea indeed. 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___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ann] CAPS 0.4.5
On 07/04/11 01:00 PM, Tim Goetze wrote: [Stefano D'Angelo] 2011/4/5 David Robillardd...@drobilla.net: On 03/04/11 04:34 AM, Stefano D'Angelo wrote: 2011/4/2 Tim Goetzet...@quitte.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. You're welcome. 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. :-) 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... 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. 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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ann] CAPS 0.4.5
On Thu, Apr 7, 2011 at 8:53 PM, David Robillard d...@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... ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ann] CAPS 0.4.5
2011/4/5 David Robillard d...@drobilla.net: On 03/04/11 04:34 AM, Stefano D'Angelo wrote: 2011/4/2 Tim Goetzet...@quitte.de: [Stefano D'Angelo] 2011/3/29 Tim Goetzet...@quitte.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.) 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... 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... 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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ann] CAPS 0.4.5
On 03/04/11 04:34 AM, Stefano D'Angelo wrote: 2011/4/2 Tim Goetzet...@quitte.de: [Stefano D'Angelo] 2011/3/29 Tim Goetzet...@quitte.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.) 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... 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? ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ann] CAPS 0.4.5
2011/4/2 Tim Goetze t...@quitte.de: [Stefano D'Angelo] 2011/3/29 Tim Goetze t...@quitte.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.) 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... ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ann] CAPS 0.4.5
[Stefano D'Angelo] 2011/3/29 Tim Goetze t...@quitte.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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ann] CAPS 0.4.5
On 30/03/11 07:40 AM, Stefano D'Angelo wrote: 2011/3/30 David Robillardd...@drobilla.net: On 29/03/11 02:59 PM, Tim Goetze wrote: [Philipp �berbacher] 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. /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. 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:replacesurn:ladspa:1234 . 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). 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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ann] CAPS 0.4.5
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... ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ann] CAPS 0.4.5
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: 2011/3/28 Tim Goetze t...@quitte.de: 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:, where 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). 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@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ann] CAPS 0.4.5
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 l...@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: 2011/3/28 Tim Goetze t...@quitte.de: 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:, where 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). 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@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ann] CAPS 0.4.5
Hi Tim, 2011/3/29 Tim Goetze t...@quitte.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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ann] CAPS 0.4.5
On 29/03/11 02:59 PM, Tim Goetze wrote: [Philipp �berbacher] 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. /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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ann] CAPS 0.4.5
[Paul Coccoli] On Sat, Mar 26, 2011 at 8:41 PM, Julien Claassen jul...@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. 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___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ann] CAPS 0.4.5
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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ann] CAPS 0.4.5
2011/3/28 Tim Goetze t...@quitte.de: [Paul Coccoli] On Sat, Mar 26, 2011 at 8:41 PM, Julien Claassen jul...@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. Thank you Julien and Paul! Aehm... there is a bug in the LRDF file, plugin CabinetI has two more model entries than the port's minimum-maximum range supports. 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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ann] CAPS 0.4.5
[Stefano D'Angelo] 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... I don't see how compatibility with LV2 is a concern here? Cheers, Tim ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ann] CAPS 0.4.5
2011/3/28 Tim Goetze t...@quitte.de: 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:, where 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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ann] CAPS 0.4.5
Excerpts from Stefano D'Angelo's message of 2011-03-28 22:59:46 +0200: 2011/3/28 Tim Goetze t...@quitte.de: 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:, where 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). ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ann] CAPS 0.4.5
On Sat, Mar 26, 2011 at 8:41 PM, Julien Claassen jul...@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! ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] [ann] CAPS 0.4.5
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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ann] CAPS 0.4.5
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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
