8 Aug
2012
8 Aug
'12
11:38 a.m.
On Tue, Aug 7, 2012 at 11:57 AM, David Robillard <d(a)drobilla.net> wrote:
On Tue, 2012-08-07 at 03:19 -0400, Jeremy Salwen
wrote:
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
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.
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
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
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:
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