My concept with GMPI (not everyone agreed) was that MIDI was not required
*in* the plugin.
For example take your MIDI keyboard's "Modulation Wheel". Imagine the
function that parses the MIDI bytes, decides what type of MIDI message it is
and typically converts that 7-bit controller to a nice 'float' scaled
between -1.0 -> +1.0. Typically every single VST synth plugin has that
code. The inefficiency is that 1000 Plugin developers had to create and
debug equivalent code.
I decided the *host* should provide that routine. Written once, available
to every plugin developer. The plugin simply exposes a port, and the
metadata says "map this port to MIDI modulation-wheel".
The advantage is - very rich MIDI support is available to ALL plugins. Not
just the standard 7-bit controllers, I support CC, RPN, NRPN, SYSEX, Notes,
Aftertouch, Tempo, almost everything. The MIDI parsing code exists only in
one place so it's robust, and it saves plugin developers a lot of wasted
time duplicating existing code. Plugins are small and lightweight, but MORE
functional than the average VST 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.
Support libraries are the solution to this, naturally, but I have
learned that people have a powerful aversion to using *anything*, no
matter how completely unoffensive a dependency it is. To address this,
LV2 will probably reluctantly grow an "SDK" that includes essentially
all my libraries soon, but I remain completely convinced that this is
awful, and the spec should be more timeless and have no ABI issues
contained in it whatsoever, and hate this idea with a passion.
I strongly disagree. That is to say, I don't think ABI issues are unimportant, but rather that I don't believe including more complex hosting functionality in a hosting library will cause this to happen. None of the proposed changes would operate through any means other than LV2 extensions. Adding additional functionality to a hosting library would neither change the requirements for plugins nor for hosts. There would be no issues with backwards compatibility, and in fact this is a perfect example of how LV2's systems of optional/required features solves such issues.
So long as you don't start including references to the SDK in the specification, neither plugins nor hosts have to worry at all about the SDK unless they want to. I find it very strange that you are concerned about this: usually the fear is with these sorts of things that the implementation will differ from the specification, and actually end up becoming the de-facto standard (see the VP8 codec, for example). But in this case it would be ridiculous to suggest that is going to happen. Every one of the libraries you are talking about, real or hypothetical, will be written by you, or under your close guidance, i.e. with a close eye at all all times towards conformance with the standard.
The only real worry is that hosts will be unhappy of the "bloat" added to the library they are using. If it really makes a difference for the library size, then the obvious solution is to separate the required functionality from the optional. This is completely doable. But at the very least, give host authors the choice between gaining the extra features, and satisfying their "powerful aversion to any dependency". But I'd bet anyways that if they truly did want to support these advanced features, most host authors would rather use the functionality in the library than have to write it on their own, and for some, it would change these features from "not worthwhile" to "worthwhile" to implement. I mean, at the root of the issue is a tradeoff, between features and complexity. If a host complains about the extra complexity that an optional feature incurs, then that's their problem, not ours. You can't have your cake and eat it too, no matter what plugin specification you are using.
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). Even on the host side of things, I was unsatisfied with the lilv c++ wrapper, so I wrote lolvmm. I mean, sure, it's hardly anything, but the point is that if developers felt the same way about any other part of the hosting libraries, then we would see alternatives develop.
If I thought that lilv had it all wrong, then I would write my own host library that does it the way I think is right. So when I make suggestions about additions to the hosting libraries, it is in the spirit of reducing duplicated effort, not because I think they are the sole "official standard of LV2". (although the practical reality that changes to lilv will translate to widespread support much more quickly than an independent venture would does color my view of the situation).
But right now, with LV2 event controls and default midi binding on the horizon, depending on how the current hosting libraries handle it, it is the first time that it is plausible (at least for me) that it would be worth it to create some manner of alternative hosting library. Because honestly, right now, what would an alternative implementation look like? Code duplication!
Jeremy Salwen