13 Aug
2009
13 Aug
'09
11:38 p.m.
On Fri, 2009-08-14 at 01:26 +0200, Fons Adriaensen wrote:
On Thu, Aug 13, 2009 at 11:16:14PM +0100, james morris
wrote:
That would be acceptable in many cases, but you can't expect
a synth user to set that checkbox when he loads the plugin
into his patch. The host should set the boolean option and
make the plugin (if it has its own GUI) remove the checkbox.
But probably it's safer to keep the 'polophony' case out of
this altogether, and let any synth host replicate the full
plugin instead. It is quite a special use case with very
specific requirements compared to general audio processing.
You're cutting the problem apart in the wrong direction, these "cases"
don't make much sense. We just need a way to replicate ports...
Polyphony does differ in that there's the additional issue of 'active'
vs 'inactive' voices, but I think that is orthogonal to actually
replicating ports. It seems a few cases have popped up where we need
this and that little bit of binary information associated with port
contents - maybe there should be a mechanism for this? In this case, of
course, that thing would be a boolean for whether this voice is active.
We don't want to have to create a new port type for "audio plus bool
active", that'll just end up in combinatorial type explosion.
How would
a port type tell e.g. a multichannel limiter plugin if
it has to limit each channel separately, or use the same gain
reduction, based on the loudest one, on all ?
All the port type (property) would do is say this port is replicated. How
the plugin handles that is down to the author. For the limiter example
you might want a boolean value (a gui check box) which the plugin acts
upon to determine this. There would still be the same number of
inputs/outputs replicated in both cases (I think)... Which leads to my next consideration: is it a good
idea at
all to expect a single plugin API to handle things as diverse
as a complete synthesiser, which could be a plugin host on
its own and require midi and maybe other non-audio interfaces,
and something as trivial as e.g. a ring modulator or a stereo
panner ? Do we really need something that would technically
allow such a synth plugin to load and replicate itself as
part of a polyphonic patch ?
In a word: yes. The basic LV2 spec - which is small, and simple - is
capable of this, so why not?
I certainly need it anyway. If you don't, then don't bother with such
things. LV2 itself does not bloat because of stuff like this. The
extension mechanism you think you don't like is what solves this
problem.
It is (to me) rather unclear what LV2 tries to be. If
it is
both that would be quite ambitious, and I don't think it would
be good idea. But I do see people asking for Zyn as an LV2,
and at the same time someone is implementing basic arithmetic
operations as LV2 plugins.
I see no problem with this whatsoever. Why the heck would you want 4
APIs instead of 1, when 1 will do? These are all things that are very
similar in scope and appropriate for LV2. Inputs, process, outputs.
Sure, not everything in the entire world is - what VAMP plugins do, for
example, is not a good match for LV2 at all - but this stuff certainly
is.
Things as complicated as Zyn do require some more complicated
extensions. You are perfectly free to ignore them and act as if they do
not exist at all. Again, the extension idea is the reason for this.
There is no problem with the scope mentioned at all, and there is no
problem with a much wider scope than that either. If it's not to your
liking, simply ignore it. People can implement all sorts of retarded
things within LV2, much like in any programming language. This doesn't
affect anyone else. You always have LADSPA+metadata if that's all you
really want.
The scope of LV2 itself is tiny, and I think it should be kept as tiny
as possible... but you have actually been arguing that the scope of LV2
should be dramatically increased! Wide scope would indeed be bad if
everything was mashed in some big messy kitchen sink specification -
just one of many reasons this is a bad thing, and it's not done this
way.
LV2 itself is very small and simple, and yet all the above fancy things
are possible. That is good design.
LV2 designed in the way you seem to think would be better would be MUCH
larger and MUCH more complicated and MUCH less capable. That is bad
design.
The tale of the tape tells it all, so to speak.
(I guess I have to bite at the whole FUD thing, so here it is:)
If you do not like the design issues involved with this kind of thing,
then just ignore them. Frankly, Fons, and I don't mean this as an
insult in any way; you're an excellent math and DSP guy (probably the
most useful person around here for that sort of thing) - but you're not
very good at design(*). If the problem is not to your liking, that
doesn't mean the problem itself is stupid. Making a good extensible
plugin API with this scope is not at all stupid, it's clearly just not
your thing. Similarly, I havn't the slightest clue how to go about
writing a filter - but I'm glad others do, because I know good filters
are useful ;)
If you have useful input, which as a plugin/app author you often do,
then fire away, but this FUD crap (and it is FUD because it is not based
on facts) really just gets in the way of things. Nothing useful can
possibly come from it.
WHY are extensions bad?
WHY is using LV2 for Zyn and arithmetic operations bad?
WHY the heck would you want a different API for a synth and a panner?
WHY? The why part is usually left out because there isn't one...
Actual concrete criticism is useful, and welcome, but constant vague
hand-wavey "LV2 is the devil just because" kind of arguments are not.
You have a lot of great plugins, many of which suffer a great deal from
the limitations of LADSPA (more so than most, actually, e.g. CV) - your
input on LV2 things is therefore probably useful, and getting your
plugins ported to LV2 would definitely benefit everyone. However, In
order for input to be useful, and for your concerns (if you have any
tangible ones) to be addressed, there has to be actual factual points in
there. That the LV2 sky is falling is not very useful...
Again, I apologize for taking this personal in a sense, but it seemed
the only way to make the point.
You point out genuine, concrete problems with LV2, or related things,
and I hereby personally promise to do my best to resolve them
(eventually), and thank you for your input; but there is really very
little I or anyone else can do with variations on "LV2 is crap".
-dr
(* and I will be the first to admit that I suck at DSP. Mathey types
who are good at design (and vice versa) are very, very few and far
between. Different modes of thinking entirely.)