Re: [LAD] LV2 Achievement of GMPI Requirements

On Tue, Aug 7, 2012 at 11:57 AM, David Robillard <d@email-addr-hidden> wrote:

> 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?
>
> 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.
>

I have no such misconception. I know that Lilv doesn't do any magic. My
suggestion was that it begin to. You emphasized the current state of lilv,
saying "Lilv doesn't really do anything like this related to run time", and
didn't speak further on the possibilities. To me, this statement coupled
with the further silence on the topic meant that you intended to keep it
this way. Anyway, I'm more pleasantly surprised that this is not the case
than I am bothered by the fact that I misunderstood you.

I completely understand that from an *implementational* point of view, midi
binding functionality is quite different than what lilv does. But from a
utilizational point of view, midi binding fits right in with the rest of
the API.

library API changes, then a host that worked with an old version of LV2
> will no longer build against a new version of LV2

...

>
> 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?
>

I had a different concept of SDK then you I thought we were talking about
the scenario above as the default case, where the SDK simply packaged the
various libraries and tools together for convenience. That the main
difference would be the unification of the documentation, and the implicit
pressure on developers to use more of the libraries. I agree that what you
were talking about: monolithic incompatible versions, would be a
mistake.but that seems like an issue orthogonal to what level of wrapping
"magic" goes into the plugin host library.

> 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 ;)
>
> Well my wrapper came out of this conversation on the drobilla tracker:
http://dev.drobilla.net/ticket/756

I then posted a link to my library a few months ago when I finished.

In the SDK model, we *don't want* to see alternatives develop. We want
> to see *improvements contributed*.
>

 I see contributions and alternatives as two sides of the same coin. To me
it is irrelevant if the alternative code exists on some dude's website or
if it get's standardized and included in the official SDK. The point is
that Joe the developer still has a choice in how he hosts his plugins.

  * 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.
>

No! We do *not* need control events for midi binding. The only thing we
need at this point is

* Appropriate properties for describing the MIDI binding of parameters

And that's what I was trying to get working on. I think you're looking to
far into the future. I have, right here, right now, a synthesizer plugin
that desperately wants default midi binding. I am telling you that if I
sat down today, with a set of properties that describe midi binding, I
could build a modified lilv shared library that implemented default midi
binding and without any compatibility changes, suddenly *every single *host
would support that feature. I could even add some extra functions so that
hosts who are aware of it could turn it off, or modify the bindings in real
time. Again, this is all with standard control ports. And when event
ports come around, we could implement the *exact same* binding
functionality, and the host wouldn't even need to know what type of control
port it is.

>
> 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.
>

But these are precisely the hosts which *don't* need default midi
bindings: you can do them manually! It's hosts like *lv2_jack_host* that
would benefit the most, because they would go from midi bindings (and in
fact any control ports) being unusable, to usable, albeit only with default
settings. That's the power of default midi bindings, that you can host a
plugin with the *simplest* midi host, and you can tweak the knobs through
your midi keyboard that the host might not even understand how to vary. I
don't see a stronger argument for how things should be done based on the
"existing host reality" than the practical benefits that this path would
offer.

I'm all for event-based control ports, but that's an issue separate from
midi binding libraries, which I think can be handled *right now*.

Jeremy

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Wed Aug 8 16:15:04 2012