[LV2] Dplug wrapper for LV2

[David Robillard]

I'll just respond to this thread free-form because it's outgrown
quoting*

I think these are important concerns, but yes, that particular issue
with ranges doesn't exist in LV2  Really though this comes down to a
slightly different philosophy.  LV2 has a philosophy of "meaningful"
controls and strong compatibility rules which are designed to prevent
exactly this sort of breakage.  It's a little fuzzy with respect to
parameter ranges and such, but in general, you can't get into a
situation like "I broke my plugin's interface and would like to restore
state across those versions" because you aren't allowed to break it in
the first place.

This is indeed limiting to plugin developers - on purpose.  Even if the
plugin was 100% responsible for restoring its state, it could not paper
over this kind of breakage with parameters, because it does not know
what the host is doing with these values.  You could, for example, have
a session with an automation lane with all kinds of fancy things going
on based on the fact that a parameter is in Hz.

If, hypothetically, the plugin developer wanted to replace that port
with a Hz/Voct parameter with a different name, sure, it could
translate that when restoring a single state snapshot, but what happens
with the user's carefully crafted automation that is a key part of
their composition?  It's broken and the plugin can't do anything about
it.

In short, the user's song is broken.  That's extremely bad.  This isn't
really something that LV2 is imposing, it's inherent that doing this
breaks things.  So, LV2 does not allow it.  Dealing with compatibility
sucks, but c'est la vie.  A plugin's control interface is like a
library API, you just have to be careful about it.

That said, we could come up with some ways of migrating between
different "versions" of a plugin (actually between different plugins
that are descendants in some fuzzy way), but this would be pretty hard
to do.  Plugins would need to implement some kind of translation layer,
and expose it, and hosts would need to detect this situation and
convert whatever parameter data (like automation) they have stored,
which would be a one-way trip, and so on.  Blech.

I doubt this is worth the effort, because what it really comes down to
is that you can't *remove* controls (or fundamentally change how they
work), which seems like a pretty reasonable restriction to me.  You can
add ports, reorder ports, kiiiiiiiiinda change ranges (we should
specify this better), and do pretty much whatever you want with your
internal state, and everything is fine.  You just can't remove a
parameter a user may have spent countless hours automating in their
composition, which seems reasonable.

There are a few areas where LV2 is hostile to developers who want the
lowest common denominator between all the plugin specs, and this is one
of them.  I think it's justified, though.  At the very least, it lets
you do neat things like 
https://drobilla.net/2014/11/03/lv2-plugin-control-units-in-ardour.html
which you can't with the meaningless normalized controls of VST.

It would probably be possible to write an extension to more properly
support this style of parameter, but it would add a burden on hosts to
use a translation/metadata/etc API provided by the plugin, and I don't
imagine that many hosts authors would be super keen on doing that. 
Particularly since it wouldn't avoid the need to solve all of the above
anyway (if 0.5 all of a sudden means something else, all of these
issues are back again).

I know that at least some internal plugin-like interfaces in
applications that care about long-term compatibility work more like LV2
than VST for these reasons.  It's possible to translate automation
between broken parameters, but it's a huge amount of work, so even when
the mechanisms are there to make it possible, there's a lot of pressure
to not break parameters, because it sucks to deal with and you break
forwards compatibility in the process.

Cheers,

-- 
dr

(* Please don't top post here)