Re: [LAD] LV2 Achievement of GMPI Requirements

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 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). 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. 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. And (unless I'm mistaken) never told me about it until now, so Lilv remains unimproved. A wonderful example of "collaboration" failing in practice ;) 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. Indeed... 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