14 Apr
2011
14 Apr
'11
3:38 a.m.
On April 13, 2011 05:03:45 pm you wrote:
On April 13, 2011 02:11:02 pm David Robillard wrote:
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.
On 12/04/11 06:00 AM, Tim Goetze 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. [David Robillard]
No, a given index on your plugin no longer refers to the same port,
therefore the interface to the plugin has been broken, period. 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.
> > 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 :)