7 Aug
2012
7 Aug
'12
9:19 a.m.
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