[Jeff McClintock] 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 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.

[David Robillard] Again: not the plugin is broken, but the host that assumes the port signature not to change over different plugin versions.

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.

It has been shown that properly designed hosts handle the port addition just fine.

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?

On April 13, 2011 02:11:02 pm David Robillard wrote: 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 :)

On 13 April 2011 22:03, Tim E. Real <termtech(a)rogers.com> wrote: 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

On Thu, 2011-04-14 at 11:59 +0100, Chris Cannam wrote: Well, that's just silly... it's the only ID there is. What else would they use?

On Sun, 2011-04-17 at 19:16 +0100, Chris Cannam wrote: 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...

On Sun, 2011-04-17 at 19:16 +0100, Chris Cannam wrote: 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.

Perhaps the LADSPA spec /should/ use that (or whatever else) as an identifier, but it doesn't.

file name + label would be a really annoying two-piece identifier anyway, even if it was an actual global identifer.

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.