Content-Type: text/plain; charset="UTF-8"
On Wed, 2012-08-08 at 05:38 -0400, Jeremy Salwen wrote:
Yes, but it is really more of an afterthought to some more fundamental
control things that need to happen. The silence is because I do not see
any interesting questions there. Things just need doing.
> I suppose if the contained libraries are parallel installable,
This is precisely what I am talking about. Putting libraries in the SDK
makes these issues happen. Libraries have compatibility issues that the
specifications do not.
> > Even on the host side of things, I was unsatisfied with the lilv
So you did. Apologies, my mistake (I really wish Trac would email about
> In the SDK model, we *don't want* to see alternatives develop. We
Well, it is not irrelevant at all. "The" way to do things being a
rotten header buried on some impossible to find website somewhere - or
sometimes one that's just gone away entirely - was a massive problem for
LV2 in the past. The extensions that defined properties and such were
Tried that, didn't work. In practice, the specs need to be curated and
maintained in the official package.
> The point is that Joe the developer still has a choice in how he
Except everything even remotely related to LV2 is *constantly* held up
by control ports. I am tired of investing effort in a mistake, and I am
definitely not breaking the Lilv API to implement magic support for a
mistake that I constantly deal with griped about.
The sooner those damned ports die the better off we all are.
> * Appropriate properties for describing the MIDI binding of parameters
Well, what you say now is considerably different from what you said in
your original email to the lv2 mailing list, and, I will say again, Lilv
does not, will not, and *can not* do this "magic" in this way. You said
you understood this...
In your original email, you were describing some odd hybrid of MIDI
parameters and control ports where the host could switch between them,
and perhaps have GUI controls which send MIDI to the plugin.
Specifically, you said:
> I was thinking about the ideal behavior from the user's point
As has been said often in this discussion, this is awful, and no, spec
work will not be done towards it. Controlling plugin parameters via
MIDI is a gigantic step backwards, and spending time bloating
hosts/libraries doing this is ridiculous. Why would you go out of your
way to have a 7-bit controller? I am completely in agreement with Jeff
on this one. It is not only awful on paper, it has been shown to be
awful in practice with other APIs. This is not the way forward.
Now, if you have control ports, and want to describe their default MIDI
bindings in the .ttl file, that is an entirely different thing.
Essentially all that is needed is a single predicate to list the MIDI
binding, since the MIDI extension already defines everything else about
I do not know which extension is most appropriate to put this predicate,
since it could be used for non-MIDI things as well. In any case,
foo:binding [ a midi:Controller ; midi:controllerNumber 27 ]
There are a few main reasons I have not done this yet:
* Nobody actually cared who was intending on actually writing code,
until you right now
* To do this in a utility API for control ports means the API depends on
the plugin instance directly, which means all the advantages of the
event based scheme in my previous mail go away, and much of the whole
thing will have to be rewritten for control events
* Static MIDI bindings don't seem very useful anyway, to me
This is not a new pattern. The theme of "oh, well, it could be done
correctly, but we have these LADSPA things that everybody despises and
suck for all sorts of other reasons, so we can kind of do it half-assed
for now and then re-do it again later" is a recurring one.
If you want to work on the host side portions of this, feel free,
however it can not be "magically" implemented in lilv as you wish (which
you will see if you try despite my suggestion). To be clear, I am not
saying I personally dislike this idea, I am saying it is not possible.
It can however be made simple, at least. Step one, and the most useful
90% of the work, would be to write code that reads that data, generates
some interim structure, which can then match against a MIDI event (i.e.
return true if and only if the MIDI event matches the binding
description). This is a necessary component of any solution. The
interim structure is required because this must be real-time safe so you
can't read from the data every time.
The 'get a value from a MIDI event' part is probably best done in a
static inline header included in the MIDI extension.
Given those two things, all the host has to do in its 'foreach event'
loop (which is usually present anyway, always in the case of hosts
writing from Jack or similar) is check if the event matches the binding
of any port, and if so sets the port value. For acceptable performance
with lots of ports and bindings, the above mentioned structure that does
this matching will have to store a port index and do the search in
Personally I think this use case is a heck of a lot more nichey than you
let on, especially since it means you need to configure your MIDI
controller to match the plugin... unless the plugin is associated with
specific hardware, how many people are about to - or even can - do that?
There is a reason MIDI learn is how it is almost always done, static
bindings on the plugin just aren't very useful in most cases.
That said, sure, support for this would be nice (largely because it can
be re-used when the bindings are more usefully stored elsewhere, but
nice nonetheless). It is unfortunately not possible to have lilv hosts
magically support this without any changes at all, but it can be made
very easy as described above.
As far as what I am about to do goes, there is quite a bit of LV2 work
that needs doing that I consider to be of much higher priority than
this. I will not be concerned with binding until we have something
worth binding, and that big red column of fail in the document that
started this thread turns green. However, patches are welcome.
P.S. Your mail client is mangling quotes in a way that makes replying
cleanly very difficult and time consuming...
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
-----END PGP SIGNATURE-----