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

On Wed, 2012-08-08 at 05:38 -0400, Jeremy Salwen wrote: [...] Yes, but it is really more of an afterthought to some more fundamental control things that need to happen. The silence is because I do not see any interesting questions there. Things just need doing. This is precisely what I am talking about. Putting libraries in the SDK makes these issues happen. Libraries have compatibility issues that the specifications do not. So you did. Apologies, my mistake (I really wish Trac would email about ticket comments!) Well, it is not irrelevant at all. "The" way to do things being a rotten header buried on some impossible to find website somewhere - or sometimes one that's just gone away entirely - was a massive problem for LV2 in the past. The extensions that defined properties and such were even worse. Tried that, didn't work. In practice, the specs need to be curated and maintained in the official package. Except everything even remotely related to LV2 is *constantly* held up by control ports. I am tired of investing effort in a mistake, and I am definitely not breaking the Lilv API to implement magic support for a mistake that I constantly deal with griped about. The sooner those damned ports die the better off we all are. Well, what you say now is considerably different from what you said in your original email to the lv2 mailing list, and, I will say again, Lilv does not, will not, and *can not* do this "magic" in this way. You said you understood this... In your original email, you were describing some odd hybrid of MIDI parameters and control ports where the host could switch between them, and perhaps have GUI controls which send MIDI to the plugin. Specifically, you said: As has been said often in this discussion, this is awful, and no, spec work will not be done towards it. Controlling plugin parameters via MIDI is a gigantic step backwards, and spending time bloating hosts/libraries doing this is ridiculous. Why would you go out of your way to have a 7-bit controller? I am completely in agreement with Jeff on this one. It is not only awful on paper, it has been shown to be awful in practice with other APIs. This is not the way forward. Now, if you have control ports, and want to describe their default MIDI bindings in the .ttl file, that is an entirely different thing. Essentially all that is needed is a single predicate to list the MIDI binding, since the MIDI extension already defines everything else about MIDI: http://lv2plug.in/ns/ext/midi I do not know which extension is most appropriate to put this predicate, since it could be used for non-MIDI things as well. In any case, something like: <someport> foo:binding [ a midi:Controller ; midi:controllerNumber 27 ] There are a few main reasons I have not done this yet: * Nobody actually cared who was intending on actually writing code, until you right now * To do this in a utility API for control ports means the API depends on the plugin instance directly, which means all the advantages of the event based scheme in my previous mail go away, and much of the whole thing will have to be rewritten for control events * Static MIDI bindings don't seem very useful anyway, to me This is not a new pattern. The theme of "oh, well, it could be done correctly, but we have these LADSPA things that everybody despises and suck for all sorts of other reasons, so we can kind of do it half-assed for now and then re-do it again later" is a recurring one. If you want to work on the host side portions of this, feel free, however it can not be "magically" implemented in lilv as you wish (which you will see if you try despite my suggestion). To be clear, I am not saying I personally dislike this idea, I am saying it is not possible. It can however be made simple, at least. Step one, and the most useful 90% of the work, would be to write code that reads that data, generates some interim structure, which can then match against a MIDI event (i.e. return true if and only if the MIDI event matches the binding description). This is a necessary component of any solution. The interim structure is required because this must be real-time safe so you can't read from the data every time. The 'get a value from a MIDI event' part is probably best done in a static inline header included in the MIDI extension. Given those two things, all the host has to do in its 'foreach event' loop (which is usually present anyway, always in the case of hosts writing from Jack or similar) is check if the event matches the binding of any port, and if so sets the port value. For acceptable performance with lots of ports and bindings, the above mentioned structure that does this matching will have to store a port index and do the search in log(n_bindings) time. Personally I think this use case is a heck of a lot more nichey than you let on, especially since it means you need to configure your MIDI controller to match the plugin... unless the plugin is associated with specific hardware, how many people are about to - or even can - do that? There is a reason MIDI learn is how it is almost always done, static bindings on the plugin just aren't very useful in most cases. That said, sure, support for this would be nice (largely because it can be re-used when the bindings are more usefully stored elsewhere, but nice nonetheless). It is unfortunately not possible to have lilv hosts magically support this without any changes at all, but it can be made very easy as described above. As far as what I am about to do goes, there is quite a bit of LV2 work that needs doing that I consider to be of much higher priority than this. I will not be concerned with binding until we have something worth binding, and that big red column of fail in the document that started this thread turns green. However, patches are welcome. -dr P.S. Your mail client is mangling quotes in a way that makes replying cleanly very difficult and time consuming...