<br><br><div class="gmail_quote">On Tue, Aug 7, 2012 at 11:57 AM, David Robillard <span dir="ltr"><<a href="mailto:d@drobilla.net" target="_blank">d@drobilla.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Tue, 2012-08-07 at 03:19 -0400, Jeremy Salwen wrote:<br>
> My concept with GMPI (not everyone agreed) was that MIDI was<br>
> not required<br>
> *in* the plugin.<br>
</div>[...]<br>
<div class="im">><br>
> This is almost exactly what I proposed as an LV2 extension in this<br>
> previous thread:<br>
><br>
> <a href="http://lists.lv2plug.in/pipermail/devel-lv2plug.in/2012-June/000270.html" target="_blank">http://lists.lv2plug.in/pipermail/devel-lv2plug.in/2012-June/000270.html</a><br>
><br>
> but David seemed to be very against putting this sort of functionality<br>
> in the hosting library.<br>
<br>
</div>Hm? Why do you say that?<br>
<br></blockquote><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
My comment about lilv was to point out that you seem to have a<br>
misconception that lilv is already wrapping plugin instances and so<br>
"magic" can be built-in to automatically deal with MIDI binding. <br></blockquote><div><br>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.<br>
<br>I completely understand that from an <i>implementational</i> 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.<br>
<br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
library API changes, then a host that worked with an old version of LV2<br>
will no longer build against a new version of LV2</blockquote><div>... <br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I suppose if the contained libraries are parallel installable, packagers<br>
could still package them independently, but if we want that... why<br>
distribute them in one package upstream in the first place? To save a<br>
tiny (if loud) niche of people from a few commands?<br></blockquote><div> <br>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.<br>
<br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im">
> Nobody gives a shit about specifications, or implementation<br>
> independence. The<br>
> better part of a decade later there's still precisely one left<br>
> alive:<br>
> mine. Time to give up those ideals I suppose)<br>
><br>
> I wouldn't be so fast to give up on those ideals. All this<br>
> demonstrates is that so far, your implementations have satisfied<br>
> everyone's needs. It's just that the degrees of freedom in<br>
> implementing an LV2 support library are too small at this point. But<br>
> that doesn't mean that it's not worth it to maintain this<br>
> implementation independence, so that as complexity develops,<br>
> alternatives can fill the necessary roles. I mean, on the plugin side<br>
> of things, we have lv2-c++-tools, which offers an alternative library<br>
> for writing plugins (although the default in this case is no library).<br>
<br>
</div><br>An unending source of nightmares and user confusion that had the gall to<br>
use the pkg-config name "lv2-plugin", so the official SDK is likely<br>
going to have to work around that nonsense, but that's another<br>
discussion... but how plugins are implemented internally isn't very<br>
important in the grand scheme of things, as long as they work according<br>
to the API.<br>
<div class="im"><br>
> Even on the host side of things, I was unsatisfied with the lilv c++<br>
> wrapper, so I wrote lolvmm.<br>
<br>
</div>And (unless I'm mistaken) never told me about it until now, so Lilv<br>
remains unimproved. A wonderful example of "collaboration" failing in<br>
practice ;)<br>
<div class="im"><br></div></blockquote><div class="im"> Well my wrapper came out of this conversation on the drobilla tracker: <a href="http://dev.drobilla.net/ticket/756">http://dev.drobilla.net/ticket/756</a> <br><br>I then posted a link to my library a few months ago when I finished.<br>
<br>
<br>
</div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">In the SDK model, we *don't want* to see alternatives develop. We want<br>
to see *improvements contributed*. <br></blockquote><div><br> 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.<br>
<br><br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* Control events<br>
* Events for announcing new parameters dynamically (I am assuming this<br>
is a requirement)<br>
* Appropriate properties for describing the MIDI binding of parameters<br>
* Events for setting/announcing that as well<br>
* Probably some kind of helper header API to make the above easier<br>
(i.e. reading/writing those events in a single function call)<br>
* An example plugin that actually uses this stuff (a multi-band EQ<br>
seems the best candidate)<br>
<br>
After all that is done, working, and established... sure, some library<br>
for automagic MIDI binding. Whatever. Right now, worrying about that<br>
is putting many carts before the horse.<br></blockquote><div><br>No! We do <i>not</i> need control events for midi binding. The only thing we need at this point is <br><br>* Appropriate properties for describing the MIDI binding of parameters<br>
<br>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 <i>every single </i>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 <i>exact same</i> binding functionality, and the host wouldn't even need to know what type of control port it is.<br>
</div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
It is also important to take a look at existing host reality, which<br>
frankly the GMPI perspective tends to lack: for example, the two main<br>
large hosts I work on, Ardour and Ingen, would probably not use this<br>
convenience layer whatsoever, since they already have their own binding<br>
mechanisms that are specific to the internals of those particular<br>
programs.<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br>But these are precisely the hosts which <i>don't</i> need default midi bindings: you can do them manually! It's hosts like <i>lv2_jack_host</i> 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 <i>simplest</i> 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.<br>
<br>I'm all for event-based control ports, but that's an issue separate from midi binding libraries, which I think can be handled <i>right now</i>.<br><br>Jeremy<br></div></div>