[LAD] LV2 Achievement of GMPI Requirements

[David Robillard]

On Tue, 2012-08-07 at 03:19 -0400, Jeremy Salwen wrote:
>         My concept with GMPI (not everyone agreed) was that MIDI was
>         not required
>         *in* the plugin.
[...]
>  
> This is almost exactly what I proposed as an LV2 extension in this
> previous thread:
> 
> http://lists.lv2plug.in/pipermail/devel-lv2plug.in/2012-June/000270.html
> 
> but David seemed to be very against putting this sort of functionality
> in the hosting library.

Hm?  Why do you say that?

All I said was lilv only contains code related to discovery and other
"data stuff".  That is what lilv is.  It seems reasonable to keep
"library that does a ton of RDF and filesystem stuff" separate from
"small library that works with plugin data, possibly in real-time", does
it not?

My comment about lilv was to point out that you seem to have a
misconception that lilv is already wrapping plugin instances and so
"magic" can be built-in to automatically deal with MIDI binding.  This
is not the case, and a library could not do this behind a run()-like
interface anyway because it would require in-place event insertion.
Library support for this would, by necessity, be on a per-event level
(see below).

>         Support libraries are the solution to this, naturally, but I
>         have
>         learned that people have a powerful aversion to using
>         *anything*, no
>         matter how completely unoffensive a dependency it is.  To
>         address this,
>         LV2 will probably reluctantly grow an "SDK" that includes
>         essentially
>         all my libraries soon, but I remain completely convinced that
>         this is
>         awful, and the spec should be more timeless and have no ABI
>         issues
>         contained in it whatsoever, and hate this idea with a
>         passion.  
> 
> I strongly disagree.  That is to say, I don't think ABI issues are
> unimportant, but rather that I don't believe including more complex
> hosting functionality in a hosting library will cause this to happen.
> None of the proposed changes would operate through any means other
> than LV2 extensions.  Adding additional functionality to a hosting
> library would neither change the requirements for plugins nor for
> hosts.  There would be no issues with backwards compatibility, and in
> fact this is a perfect example of how LV2's systems of
> optional/required features solves such issues. 

Except there *would* be issues of backwards compatibility, namely if a
library API changes, then a host that worked with an old version of LV2
will no longer build against a new version of LV2.

Since all the libraries have been put in a single package, there will be
no more old version that could be parallel installed, so there is
breakage.  Even worse, if plugins start using these libraries, then
plugins depend on system libraries and they can be broken by upgrading
too.  All of these problems are not present with an lv2 package that
contains only specs.

I suppose if the contained libraries are parallel installable, packagers
could still package them independently, but if we want that... why
distribute them in one package upstream in the first place?  To save a
tiny (if loud) niche of people from a few commands?

Or, there is the more benevolent dictator approach, where I say: yes, it
may break, and if it does, update your code.  No sympathy for old crap.

Naturally, ABI breakage is kept as infrequent as possible (none of these
libraries have broken ABI since their original release), but it still
must be accounted for somehow.

As you can see, it is not a straightforward issue at all.  For
libraries, there are established best practices for how to deal with
this stuff.  The hypothetical LV2 SDK is not one library, so there is
not.

>         Nobody gives a shit about specifications, or implementation
>         independence.  The
>         better part of a decade later there's still precisely one left
>         alive:
>         mine.  Time to give up those ideals I suppose)
> 
> I wouldn't be so fast to give up on those ideals.  All this
> demonstrates is that so far, your implementations have satisfied
> everyone's needs.  It's just that the degrees of freedom in
> implementing an LV2 support library are too small at this point.  But
> that doesn't mean that it's not worth it to maintain this
> implementation independence, so that as complexity develops,
> alternatives can fill the necessary roles.  I mean, on the plugin side
> of things, we have lv2-c++-tools, which offers an alternative library
> for writing plugins (although the default in this case is no library).

An unending source of nightmares and user confusion that had the gall to
use the pkg-config name "lv2-plugin", so the official SDK is likely
going to have to work around that nonsense, but that's another
discussion... but how plugins are implemented internally isn't very
important in the grand scheme of things, as long as they work according
to the API.

>   Even on the host side of things, I was unsatisfied with the lilv c++
> wrapper, so I wrote lolvmm.

And (unless I'm mistaken) never told me about it until now, so Lilv
remains unimproved.  A wonderful example of "collaboration" failing in
practice ;)

>   I mean, sure, it's hardly anything, but the point is that if
> developers felt the same way about any other part of the hosting
> libraries, then we would see alternatives develop.

In the SDK model, we *don't want* to see alternatives develop.  We want
to see *improvements contributed*.  That is a very large part of the
point.  If anything, the goal is to *discourage* alternatives, because
if someone spends all the effort to make one, it means the SDK is
inadequate in some way.  It shouldn't be.

As functionality gets more advanced, writing a full host library suite
becomes more difficult.  It is already far more than what can be
reasonably expected of someone who simply wants a host, which is why the
libraries exist.  It was an original goal of LV2 to assume that
libraries will relieve implementation burden, and "from scratch"
implementations are not expected.  I think reality has caught up to this
goal, and it's time to consider "official" library support.

> Because honestly, right now, what would an alternative implementation
> look like?  Code duplication!
 
Indeed...

> But right now, with LV2 event controls and default midi binding on the
> horizon, depending on how the current hosting libraries handle it

Yes, back to this.  It is not clear to me exactly what you want from
host libraries on this.  Clearly you very strongly feel host libraries
need to support this, but... how, exactly?

Given a simple way of building a control event, which of course
must/will exist regardless, the only thing related to MIDI binding
that seems to need doing is figuring out what parameter is bound to
which control (this is more "data stuff"), and actually getting
parameter values from MIDI events, the latter of which is a few one
liners in a header somewhere at best.

I suppose you want some API that itself internally keeps track of MIDI
bindings of a plugin, and reads whatever MIDI event, and outputs the
appropriate control event for the plugin, if one is appropriate?  I
suppose that would be nice.

That said, it is not really worth worrying about until we actually have
control events anyway, though.  This is just some shiny stuff built on
top of infrastructure that does not exist yet.  Before anything at
nearly this level matters, we need:

 * Control events
 * Events for announcing new parameters dynamically (I am assuming this
is a requirement)
 * Appropriate properties for describing the MIDI binding of parameters
  * Events for setting/announcing that as well
 * Probably some kind of helper header API to make the above easier
(i.e. reading/writing those events in a single function call)
 * An example plugin that actually uses this stuff (a multi-band EQ
seems the best candidate)

After all that is done, working, and established... sure, some library
for automagic MIDI binding.  Whatever.  Right now, worrying about that
is putting many carts before the horse.

It is also important to take a look at existing host reality, which
frankly the GMPI perspective tends to lack: for example, the two main
large hosts I work on, Ardour and Ingen, would probably not use this
convenience layer whatsoever, since they already have their own binding
mechanisms that are specific to the internals of those particular
programs.  This is one of many reasons why building bottom up is best:
often you find you don't need to build as high as you thought.

-dr

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20120807/6c99a257/attachment.pgp>