Re: [LAD] LV2 Achievement of GMPI Requirements

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: David Robillard <d@...>
Cc: <linux-audio-dev@...>, Jeff McClintock <jef@...>
Date: Tuesday, August 7, 2012 - 7:19 am

--f46d042de58959e45c04c6a7d092
Content-Type: text/plain; charset=ISO-8859-1

>

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

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.

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

--f46d042de58959e45c04c6a7d092
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

My concept with GMPI (not=
everyone agreed) was that MIDI was not required
*in* the plugin.
=A0 For example take your MIDI keyboard's "Modulation Wheel".=
=A0Imagine the
function that parses the MIDI bytes, decides what type of MIDI message it i=
s
and typically converts that 7-bit controller to a nice 'float' scal=
ed
between -1.0 -> +1.0. =A0Typically every single VST synth plugin has tha=
t
code. =A0The inefficiency is that 1000 Plugin developers had to create and<=
br>
debug equivalent code.
=A0I decided the *host* should provide that routine. Written once, availabl=
e
to every plugin developer. =A0The plugin simply exposes a port, and the
metadata says "map this port to MIDI modulation-wheel".
=A0 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<=
br>
one place so it's robust, and it saves plugin developers a lot of waste=
d
time duplicating existing code. Plugins are small and lightweight, but MORE=

functional than the average VST plugin.=A0This is=
almost exactly what I proposed as an LV2 extension in this previous thread=
:http://lists.lv2plug.in/pipermail/devel-lv2plug.in/201=
2-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. =A0To address this,
LV2 will probably reluctantly grow an "SDK" that includes essenti=
ally
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. =A0I strongly disagree.=A0 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 happe=
n.=A0 None of the proposed changes would operate through any means other th=
an LV2 extensions.=A0 Adding additional functionality to a hosting library =
would neither change the requirements for plugins nor for hosts.=A0 There w=
ould be no issues with backwards compatibility, and in fact this is a perfe=
ct example of how LV2's systems of optional/required features solves su=
ch issues.

=A0So long as you don't start including references to the SDK in th=
e specification, neither plugins nor hosts have to worry at all abou=
t the SDK unless they want to.=A0=A0 I find it very strange that you are co=
ncerned about this: usually the fear is with these sorts of things that the=
implementation will differ from the specification, and actually end up bec=
oming the de-facto standard (see the VP8 codec, for example).=A0 But in thi=
s case it would be ridiculous to suggest that is going to happen.=A0 Every =
one of the libraries you are talking about, real or hypothetical, will be w=
ritten by you, or under your close guidance, i.e. with a close eye at all a=
ll times towards conformance with the standard.

The only real worry is that hosts will be unhappy of the "bloat&qu=
ot; added to the library they are using.=A0 If it really makes a difference=
for the library size, then the obvious solution is to separate the require=
d functionality from the optional.=A0 This is completely doable.=A0 But at =
the very least, give host authors the choice between gaining the extra feat=
ures, and satisfying their "powerful aversion to any dependency".=
But I'd bet anyways that if they truly did want to support these advan=
ced features, most host authors would rather use the functionality in the l=
ibrary than have to write it on their own, and for some, it would change th=
ese features from "not worthwhile" to "worthwhile" to i=
mplement.=A0 I mean, at the root of the issue is a tradeoff, between featur=
es and complexity.=A0 If a host complains about the extra complexity that a=
n optional feature incurs, then that's their problem, not ours.=
=A0 You can't have your cake and eat it too, no matter what plug=
in specification you are using.

Nobody
gives a shit about specifications, or implementation independence. =A0The
better part of a decade later there's still precisely one left alive:
mine. =A0Time to give up those ideals I suppose)I wouldn&#=
39;t be so fast to give up on those ideals.=A0 All this demonstrates is tha=
t so far, your implementations have satisfied everyone's needs.=A0 It&#=
39;s just that the degrees of freedom in implementing an LV2 support librar=
y are too small at this point.=A0 But that doesn't mean that it's n=
ot worth it to maintain this implementation independence, so that as comple=
xity develops, alternatives can fill the necessary roles.=A0 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 lib=
rary).=A0 Even on the host side of things, I was unsatisfied with the l=
ilv c++ wrapper, so I wrote lolvmm.=A0 I mean, sure, it's hardly anythi=
ng, but the point is that if developers felt the same way about any other p=
art of the hosting libraries, then we would see alternatives develop.

If I thought that lilv had it all wrong, then I would write my o=
wn host library that does it the way I think is right.=A0 So when I make su=
ggestions about additions to the hosting libraries, it is in the spirit of =
reducing duplicated effort, not because I think they are the sole "off=
icial standard of LV2".=A0 (although the practical reality that change=
s to lilv will translate to widespread support much more quickly than an in=
dependent 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 th=
e first time that it is plausible (at least for me) that it would be worth =
it to create some manner of alternative hosting library.=A0 Because honestl=
y, right now, what would an alternative implementation look like?=A0 Code d=
uplication!

Jeremy Salwen

--f46d042de58959e45c04c6a7d092--

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
Re: [LAD] LV2 Achievement of GMPI Requirements, Jeff McClintock, (Fri Aug 3, 10:10 pm)
Re: [LAD] LV2 Achievement of GMPI Requirements, David Robillard, (Sat Aug 4, 2:27 am)
Re: [LAD] LV2 Achievement of GMPI Requirements, Jeremy Salwen, (Tue Aug 7, 7:19 am)
Re: [LAD] LV2 Achievement of GMPI Requirements, David Robillard, (Tue Aug 7, 3:57 pm)
Re: [LAD] LV2 Achievement of GMPI Requirements, Jeremy Salwen, (Wed Aug 8, 9:38 am)
Re: [LAD] LV2 Achievement of GMPI Requirements, David Robillard, (Wed Aug 8, 3:22 pm)