1 Nov
2009
1 Nov
'09
12:35 p.m.
On Sun, 2009-11-01 at 10:10 -0400, Paul Davis wrote:
On Sun, Nov 1, 2009 at 7:53 AM, Stefano D'Angelo
<zanga.mail(a)gmail.com> wrote:
What problem does this solve? The functionality itself is defined in
terms of specific features. Host and plugin authors can talk about
support for "the transport extension", or whatever, as they do now.
Is there any real point to this other than blind VST emulation? I don't
think it has ever once come up that someone needs to talk about some
specific large set of extensions as a whole and it's tedious to
enumerate them all, or whatever.
This kind of effort is mostly a time sink for people who are powerfully
inclined to making baroque categorizations for everything. It seems to
be an almost religious fervor with some people (who should never be let
within 100 feet of a design document), I find the whole thing really
kind of amazing.
Anyway! More concretely, the reasons this is silly are obvious if you
think about it. There is simply no such categorization. Blahrdour
likes "effects" and "synths", can support "presets", has a
concept of
"transport". Blingen likes "effects" and "synths" as well,
can support
"presets", has no concept of "transport". Which category does
"transport" go into, then? It's not really related to any of the other
things at all, it's a completely independent feature. This is true of
most extensions.
Even if one came up with such a baroque categorization, it would be
worthess, because the number of exceptions would pretty much the same as
the number of supported things anyway. Pretending that everything would
fit into these nice little boxes to support the effort is silly - they
won't.
Now, that said, there is ONE such "standard" that I do support - namely
extensions that have been peer-reviewed (on the lv2 dev mailing list),
accepted by consensus, and implemented by at least 2 plugins and hosts
(this is already the consensus on what gets to have a http://lv2plug.in
URI). This is definitely a good idea, and if someone wants to come up
with a fancy name for it, feel free. Multiple categorizations is a
fool's errand, but making clear what the community has taken a good look
at and accepted, and what's just some random kludgey thing patching a
hole for somebody in the short term, is definitely a high priority goal.
-dr
Sorry, I didn't really get what you were
meaning then.
In this case it's surely possible, but would it really be much more
"readable" to use a number than to state the name of such extensions
or, even better, define sets of extensions as "levels"?
I mean, 10 extensions means numbers from 0 to 1023, and you have to
know binary arithmetics to make sense of which extensions are
supported... not very marketing friendly. Better to define "level 1",
"level 2", etc. IMO.
i meant to use a name. LV2-E<N> would simply mean LV2 core + {some
defined set of extensions}. plugin and host authors could then talk
about using "LV2-E<N>".
the E<N> part merely designates a particular set of extensions, which
might be 2 extensions, or 100.