Content-Type: text/plain; charset="UTF-8"
On Tue, 2012-08-07 at 03:19 -0400, Jeremy Salwen wrote:
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
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
> Support libraries are the solution to this, naturally, but I
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
> Nobody gives a shit about specifications, or implementation
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++
And (unless I'm mistaken) never told me about it until now, so Lilv
remains unimproved. A wonderful example of "collaboration" failing in
> I mean, sure, it's hardly anything, but the point is that if
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
> But right now, with LV2 event controls and default midi binding on the
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.
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
-----END PGP SIGNATURE-----