[LV2] Dplug wrapper for LV2

[David Robillard]

On Thu, 2019-03-28 at 12:06 +0100, Auburn Sounds wrote:
> Hi David,
> 
> As a co-implementor with Ethan, what striked me the most as possible
> improvements with LV2 were:
> 
> 1. It seems a LV2 host will look at port values to save/restore plug-
> in state. I'm concerned this is similar to VST2-without-chunks, and
> it restrict forward-compatibility with plug-ins ; we'd prefer to move
> to byte chunks instead, that the host cannot understand. There is a
> "state" extension but it doesn't seem to override this behaviour of
> saving ports. With VST2 not using chunks from the get go has been
> really painful, as you don't know what the host will do when the
> parameter number changes, also you don't know how hosts stores and
> remap parameters. This is the most important problem I see.

I am no sure what you mean here.  How would the host be
saving/restoring the plugin state if it didn't save the parameter
values?  Plugins can not set their own control ports, so their values
have to be saved and restored.  Control ports are a questionable
mechanism in many ways, and maybe this is one of them, but c'est la
vie.

The strong identifier for ports is not the number (index) but the
symbol.  You can change the index between versions all you like, this
can not break anything.  You can't change or remove symbols in a way
that would break things, though.  That would be a different plugin
(have a different URI).  See http://lv2plug.in/ns/lv2core#symbol

The state extension does allow plugins to restore their state
internally, and by using message-based parameters (like eg-params) it
is possible to make a plugin entirely responsible for saving and
restoring its state, but support for this kind of parameter is less
widespread (we should do some work here...)

Opaque blobs are, IMO, a bad idea, so the state extension encourages
transparent state so it can be portably saved in whatever way makes the
most sense for the host, easily investigated by the user, and so on,
but you *can* save blobs if you really want to.

> 2. I was looking for a way to describe an in-memory entry-point
> instead of a lv2:binary that is a file. This would allows LV2 to
> shine as an internal format within an audio application : the TTL
> would then be generated dynamically in a way that doesn't have to be
> specified. 
> Lots of companies end up implementing host and clients for plugins
> within plug-ins ; a simple "audio module" interface end up being
> exactly the same thing as... a plug-in and as such better follow a
> plugin specification. Some build this upon VST3.

Interesting idea.  I don't think this has ever come up.  There are two
separate things here, though: an entry point that isn't from a dynamic
module, and generating the data somehow.

I could maybe actually use the first in ingen... I'll have a think
about it.

The second is much harder.  There is dyn-manifest, but pretty much
everyone agrees it's a bit nutty.  I think it would be really nice to
have the ability to have plugins defined only in code (and it would
certainly remove a barrier for some people who hate the Turtle part),
but it's tricky.  Doing this by generating actual syntax isn't great,
we would need to define an API where plugins can somehow describe
things (including themselves).  Conveniently, our data model is really
simple to ram through an interface, and we have powerful enough data
types these days (atoms) to do it, but I'm not quite sure how it would
fit together.

This would also allow things to dynamically change, maybe even so far
as things like dynamic ports.  LV2_Options_Interface is a little bit
close to something like this, you can describe whatever with it, but
it's not powerful enough to do this job.  I think something along the
lines of

typedef void (*StatementFunc)(
  URID subject, URID predicate, Atom object);

void
describe_myself(StatementFunc property)
{
    property(my_plugin, rdfs_label, "Superplug");
    property(my_plugin, lv2_port, my_gain_port);
   
property(my_gain_port, lv2_value, 42.0);
    // ...
}

could do it though (slightly hand-wavey pseudocode, in reality would be
a bit more raw).  This nicely avoids the data structure and memory
management headaches of somehow needing to pass the host a description

My real dream here is to totally unify the data side of things and
code, so lilv would transparently get the information from either the
static data, or by calling plugin code as necessary.

> LV2 did strike us as something well thought out - which is uncommon
> as far as plug-in formats are concerned - , built for extensibility
> (with the pros and cons this brings), and not much accidental
> complexity.

More accidental complexity and messiness than I'd like, but thanks :)

-- 
dr