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: Wednesday, August 8, 2012 - 9:38 am

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

On Tue, Aug 7, 2012 at 11:57 AM, David Robillard wrote:

> On Tue, 2012-08-07 at 03:19 -0400, Jeremy Salwen wrote:

I have no such misconception. I know that Lilv doesn't do any magic. My
suggestion was that it begin to. You emphasized the current state of lilv,
saying "Lilv doesn't really do anything like this related to run time", and
didn't speak further on the possibilities. To me, this statement coupled
with the further silence on the topic meant that you intended to keep it
this way. Anyway, I'm more pleasantly surprised that this is not the case
than I am bothered by the fact that I misunderstood you.

I completely understand that from an *implementational* point of view, midi
binding functionality is quite different than what lilv does. But from a
utilizational point of view, midi binding fits right in with the rest of
the API.

library API changes, then a host that worked with an old version of LV2

...

>

I had a different concept of SDK then you I thought we were talking about
the scenario above as the default case, where the SDK simply packaged the
various libraries and tools together for convenience. That the main
difference would be the unification of the documentation, and the implicit
pressure on developers to use more of the libraries. I agree that what you
were talking about: monolithic incompatible versions, would be a
mistake.but that seems like an issue orthogonal to what level of wrapping
"magic" goes into the plugin host library.

> Nobody gives a shit about specifications, or implementation

http://dev.drobilla.net/ticket/756

I then posted a link to my library a few months ago when I finished.

In the SDK model, we *don't want* to see alternatives develop. We want

I see contributions and alternatives as two sides of the same coin. To me
it is irrelevant if the alternative code exists on some dude's website or
if it get's standardized and included in the official SDK. The point is
that Joe the developer still has a choice in how he hosts his plugins.

* Control events

No! We do *not* need control events for midi binding. The only thing we
need at this point is

* Appropriate properties for describing the MIDI binding of parameters

And that's what I was trying to get working on. I think you're looking to
far into the future. I have, right here, right now, a synthesizer plugin
that desperately wants default midi binding. I am telling you that if I
sat down today, with a set of properties that describe midi binding, I
could build a modified lilv shared library that implemented default midi
binding and without any compatibility changes, suddenly *every single *host
would support that feature. I could even add some extra functions so that
hosts who are aware of it could turn it off, or modify the bindings in real
time. Again, this is all with standard control ports. And when event
ports come around, we could implement the *exact same* binding
functionality, and the host wouldn't even need to know what type of control
port it is.

>

But these are precisely the hosts which *don't* need default midi
bindings: you can do them manually! It's hosts like *lv2_jack_host* that
would benefit the most, because they would go from midi bindings (and in
fact any control ports) being unusable, to usable, albeit only with default
settings. That's the power of default midi bindings, that you can host a
plugin with the *simplest* midi host, and you can tweak the knobs through
your midi keyboard that the host might not even understand how to vary. I
don't see a stronger argument for how things should be done based on the
"existing host reality" than the practical benefits that this path would
offer.

I'm all for event-based control ports, but that's an issue separate from
midi binding libraries, which I think can be handled *right now*.

Jeremy

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

On Tue, Aug 7, 2012 at 11:57 AM, David R=
obillard <d@drobilla.net> wrote:

On Tue, 2012-08-07 at 03:19 -0400, Jeremy Salwen wrote:

DI was
[...]
2plug.in/2012-June/000270.html

> in the hosting library.

Hm? =A0Why do you say that?

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. =
I have no such misconception.=A0 I know that Lilv=
doesn't do any magic.=A0 My suggestion was that it begin to.=A0 You em=
phasized the current state of lilv, saying "Lilv doesn't really do=
anything like this related to run time", and didn't speak further=
on the possibilities.=A0 To me, this statement coupled with the further si=
lence on the topic meant that you intended to keep it this way.=A0 Anyway, =
I'm more pleasantly surprised that this is not the case than I am bothe=
red by the fact that I misunderstood you.

I completely understand that from an implementational point of v=
iew, midi binding functionality is quite different than what lilv does.=A0 =
But from a utilizational point of view, midi binding fits right in with the=
rest of the API.

library API changes, then a host that worked with an old version of LV2
will no longer build against a new version of LV2... =

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? =A0To save a
tiny (if loud) niche of people from a few commands?=
=A0I had a different concept of SDK then you=A0 I thought we were talki=
ng about the scenario above as the default case, where the SDK simply packa=
ged the various libraries and tools together for convenience.=A0 That the m=
ain difference would be the unification of the documentation, and the impli=
cit pressure on developers to use more of the libraries.=A0 I agree that wh=
at you were talking about: monolithic incompatible versions, would be a mis=
take.but that seems like an issue orthogonal to what level of wrapping &quo=
t;magic" goes into the plugin host library.

> =A0 =A0 =A0 =A0 Nobody gives a shit about specifications, or implement=
ation

ely one left
br>
t
de
br>

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 like=
ly
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.

> =A0 Even on the host side of things, I was unsatisfied with the lilv c=
++

And (unless I'm mistaken) never told me about it until now, so Li=
lv
remains unimproved. =A0A wonderful example of "collaboration" fai=
ling in
practice ;)
=A0Well my wrapp=
er came out of this conversation on the drobilla tracker: http://dev.drobilla.net/ticket/756 I then posted a link to my library a few months ago when I finished.

In the SDK model, w=
e *don't want* to see alternatives develop. =A0We want
to see *improvements contributed*. =A0=A0I see co=
ntributions and alternatives as two sides of the same coin.=A0 To me it is =
irrelevant if the alternative code exists on some dude's website or if =
it get's standardized and included in the official SDK.=A0 The point is=
that Joe the developer still has a choice in how he hosts his plugins.

=A0
* Control events
=A0* Events for announcing new parameters dynamically (I am assuming this
is a requirement)
=A0* Appropriate properties for describing the MIDI binding of parameters
=A0 * Events for setting/announcing that as well
=A0* Probably some kind of helper header API to make the above easier
(i.e. reading/writing those events in a single function call)
=A0* 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. =A0Whatever. =A0Right now, worrying about that<=
br>
is putting many carts before the horse.No!=A0 We =
do not need control events for midi binding.=A0 The only thing we ne=
ed at this point is * Appropriate properties for describing the MID=
I binding of parameters

And that's what I was trying to get working on.=A0 I think you'=
re looking to far into the future.=A0 I have, right here, right now, a synt=
hesizer plugin that desperately wants default midi binding.=A0 I am telling=
you that if I sat down today, with a set of properties that describe midi =
binding, I could build a modified lilv shared library that implemented defa=
ult midi binding and without any compatibility changes, suddenly every s=
ingle host would support that feature.=A0 I could even add some extra f=
unctions so that hosts who are aware of it could turn it off, or modify the=
bindings in real time.=A0 Again, this is all with standard control ports.=
=A0 And when event ports come around, we could implement the exact same<=
/i> binding functionality, and the host wouldn't even need to know what=
type of control port it is.

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.<=
/blockquote>But these are precisely the hosts which don't need default midi bindings:=A0 you can do them manually! It's hosts =
like lv2_jack_host that would benefit the most, because they would g=
o from midi bindings (and in fact any control ports) being unusable, to usa=
ble, albeit only with default settings.=A0 That's the power of default =
midi bindings, that you can host a plugin with the simplest midi hos=
t, and you can tweak the knobs through your midi keyboard that the host mig=
ht not even understand how to vary.=A0 I don't see a stronger argument =
for how things should be done based on the "existing host reality&quot=
; than the practical benefits that this path would offer.

I'm all for event-based control ports, but that's an issue sepa=
rate from midi binding libraries, which I think can be handled right now=
.Jeremy

--047d7b33d08866ab0c04c6bddfd3--

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)