On 11 May 2007, at 16:56, Fons Adriaensen wrote:
A second reason would be that using different init() and run()
functions,
not in function of user-level functionality but just to support
some types
of algorithm complicates a host for no good reason. OTOH the extra
data
required to support multi-channel, multi-rate and block-oriented algos
is minimal, it doesn't complicate a host or get in the way of
anything,
and can be simply be ignored if you don't need it.
I don't support the idea of adding multirate (in the resampling
sense) support to LV2, I think it can be handled better by other APIs.
Multi-channel is non issue as far as I can see.
Block oriented needs some thought and experimentation, but the
existing extension seems fine to me, as a first cut. Experience will
show whether its sufficient and appropriate to the problem. I'll note
that there already several block-based LADSPA plugins, where LADSPA
has zero support for these features, you have to suffer compromises,
its ugly, and they don't work in the general case, just common case,
but it is possible.
Thirdly, since it seems already impossible to explain this to the core
designers, I won't hold my breath until some host developers
understand
why some simple things are necessary, and implement them. It will not
happen. Which means that I can't write the plugins I'd want to write
because no host will support them. And if I have to write both the
host
and the plugins, I could as well use any other API that does the job.
There's necessary in order to not make things any worse than the
status quo, and there's necessary to implement some hypothetical
plugins that don't yet exist.
Entering into a "jam tomorrow" discussion of everyone's pet features
is at best fraught and at worst fatal to the process. You might think
that there are only 3 things missing, but so does everyone else, and
they wont be the same 3 things. After a while you have GMPI over-
specification hell.
LV2 offers several useful features out of the box that LADSPA
doesn't*, and it's long overdue, so I think any suggestion that it
would be a bad thing to standardise it asis, is nonsense. When we
have experience of, and consensus on things such as block-based
processing we can produce a 1.1 spec that mandates them.
* fixing the nasty UID issue, port symbols and port connected-ness
spring to mind.
- Steve
_______________________________________________
Linux-audio-dev mailing list
[email protected]
http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-dev
