[LAD] How to develop guis for LV2?
fons at kokkinizita.net
fons at kokkinizita.net
Fri Nov 6 11:08:30 UTC 2009
On Thu, Nov 05, 2009 at 06:21:03PM -0500, David Robillard wrote:
> Something about how things refer to ports had to be clarified/changed in
> the core spec. Unfortunate, but them's the ropes. Extremely unlikely
> that something similar happens again (since there isn't much in the core
> spec to change in the first place).
(having read your other post wich outlines the technicalities)
This could have been done as an extension. I agree that would
have created some chaos, so changing the core spec was probably
a wise choice. But that's the point: this can happen at any time
with extensions. If you have N extensions, how big is the chance
that not any subset of S <= N of them will not be in conflict
somehow ? Or depend on things that are specified nowhere, such
as the order in which a host should use them and call any new
extension specific functions in the plugin ? What mechanism is
there in LV2's core spec that ensures that extensions will be
orthogonal to each other, even if written by authors who don't
know each other's work, and evaluated by a host in unspecified
> Nobody has to "accept" anything.
I'm not going to spend even a minute writing a plugin or
a set of them, requiring maybe five new extensions, if I'm
not absolutely sure that these extensions will be accepted
(that is: implemented) by the authors of the major host
programs, e.g. Ardour. And don't ask me to do that myself.
It would take ages for me to get familiar enough with e.g.
Ardour's internal structures and code to be able to do that.
And even then, the patches would still have to be accepted
by Ardour's core team. And that's only _one_ host, be it an
Currently I'm designing a rather large app that will rely
a lot on plugins. It will have at least three incompatible
types of them. By incompatible I mean that if the types are
A,B,C, it would be completely pointless to try and insert
e.g. a B where an A is expected and so on. All of them
require _embedded_ GUIs, to the point that a user will
not even be aware that some parts of the app are plugins.
Some of them require quite complex interaction with the
core of the app, not just a set of audio and traditional
control values. Type A could probably be used outside the
app as well, if you strip some its features, for the others
the chances that they can be re-used as plugins are zero.
Should I try and use LV2 for all of this ? It would create
a lot of extra complexity, starting with having to squeeze
everything through a C interface while both sides are C++,
a lot of textual representation of fixed things just adding
overhead, and a collection of extensions that I'm pretty
sure no other host will ever implement. So the answer is
no, unless I missed something.
There are much simpler solutions available. If I define each
of A,B,C as a C++ base class then any .so that provides a
factory for a derived class of any of them is a plugin. And
that's it. Of course this could mean issues with C++ binary
compatibility, but in this case, given that most of this
will never be used elsewhere anyway and distributed as a
single package, I accept those.
Io lo dico sempre: l'Italia è troppo stretta e lunga.
More information about the Linux-audio-dev