On Tue, Aug 7, 2012 at 11:57 AM, David Robillard
<d@drobilla.net> 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.
[...]
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