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 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@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Thu Apr 14 08:15:06 2011