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 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