On Sun, 2009-11-08 at 21:24 +0200, Nedko Arnaudov wrote:
Well, there are certainly a lot of people complaining about it, so that
suggests the plugin authors /aren't/ doing it. Somebody has to.
The wiki provides a way for those prone to whining to actually do
something about it. A central overview of the state of compatibility
would be useful anyway, and seems to be largely what people are asking
for. If the information was spread all over the place there would be
much less utility for people looking for which extensions it is wisest
to use (e.g. Gabriel).
IMO 99.99% of these complaints are really just about people going to
lv2plug.in looking for information and finding a big random pile of
inconsistent crap. People seem to like to extrapolate this to some kind
of argument about the technology, but they are wrong. There needs to be
a good, coherent, and consistent source of documentation for things LV2,
to address these concerns.
I am dealing with this problem as far as extensions goes, but not the
"what supports what" stuff.
New idea: it is tempting to define a very simple turtle document format
for hosts to signify what they support, then this kind of compatibility
information could be automatically generated as well (and in a much more
useful form than a human could put together). The information is
already there for plugins. As far as I'm concerned the lack of
automatically generated documentation (and/or machine readable data in
general) is pretty much the sole reason for every single complaint
related to this whole thing. This way is also decentralized, but the
results for all "known" implementations could be hosted at lv2plug.in
(or anywhere else) for convenience.
I am surprised I didn't think of this before, but it seems to be a
pretty good idea. All that is needed as far as maintenance goes is for
hosts to supply a simple turtle document that says "I implement foo and
bar and baz extensions". The rest can be compiled into whatever fancy
human readable form you want, for every single plugin out there, by a
tool. If I provide a template, would anyone be willing to put together
these documents? I will gladly write the tool if the data is there, and
the problem will be solved, and a convention set that solves it in the
future with basically no effort involved.
> IMHO, the two basic questions that user will have are:
3. How "well supported" is this extension, and should I use it in my new
This question needs an overview. Even if plugin and host authors supply
this information, an overview is useful.
Linux-audio-dev mailing list