I suppose it could. Though why is far beyond me... what's your point?
Such an extension would effectively embed a
completely new
plugin standard into LV2, leaving only the plugin discovery
and packaging mechanism.
... and?
Supporting it would be no more complex than
supporting e.g.
both dynparams and port groups, so there's no technical
rationale for refusing such an extension. There could be an
ideological one of course. But if that is enough to refuse an
extension, then ideological attacks on LV2 are legitimate as
well.
I don't know where you're getting this "accept" and "refuse"
nonsense,
as if there's some LV2 cabal that has to approve everything you do.
This is pretty much completely contrary to the entire point. You want
to attack LV2 by constructing an extension that would be "refused" by
authority? What? The whole point is that this can't happen (though you
yourself have advocated several times that it SHOULD be monolithic and
authoritarian so this kind of crap could happen, so I don't know how you
can possibly try and use this argument now).
Once again, Fons, you criticize what you clearly do not understand,
based on arguments that are pretty much entirely based on said ignorance
(and blatantly in contradiction with others you've made in the past).
Why?
-dr
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
I'm pretty sure Fons is occasionally a very smart and effective troll ;)
As a gedankenexperiment what are the problems in LV2 that make it
ineffective or even inelegant for implementing something like Jconv
i.e a wrapper on your very lovely zita-convolver? How should these be
solved?
Loki