2 Jun
2008
2 Jun
'08
11:08 a.m.
"Stefano D'Angelo" <zanga.mail(a)gmail.com> writes:
Windows has DllMain() instead.
Apart from the RDF/Turtle thing which I won't pop up for the goodness
of everyone :-), the complexity is not in LV2 itself but in its usage
in applications where sound processing is not a central topic, IMO.
VSTs are much more complex IMHO
See above.
where? complexity? I wouldnt call XML GUI DTD simple...
There is
nothing wrong with using LV2 (and probably LADSPA too) on
non-UNIX platforms.
Just an example: sometime ago I asked on IRC why there was not a
global init()/fini() function for LADSPA and was answered that ELF
defines .init and .fini sections. Which is fine for ELF-based systems
and other systems having similar stuff (all biggest platforms?), but
where there is none... Then I see this in LV2:
The environment variable LV2_PATH, if present, should
* contain a colon-separated path indicating directories (containing
* plugin bundle subdirectories) that should be searched (in order)
* for plugins.
Doesn't it sound a bit UNIX-centered? (colon separated on Windows for example?)
I bet nobody will complain if Windows developer requests to extend the
documentation with using semicolons instead on Windows.
b. Some things which, IMHO, belong to the core of a
sound processing
API like "time stretching" are almost impossible (LADSPA) or overly
complex (LV2) to do with such APIs, probably because they weren't
designed for this kind of usage; in other words, the audience is quite
different IMO.
What is complex with LV2 exactly? LV2 is designed to be extendable. Yes, it's a powerful, extendable API which can do
pretty much
everything... but compare it to the broken and ridiculous XMMS effect
plugin API and see the difference of work required to the host
author.... don't you get anything?
you should compare XMMS plugins to GSteamer plugins, really...
Another example: doing something like that "time
stretching" thing
would mean having, among other stuff, another run()-like callback in a
dedicated extensions, and the original run() wouldn't work also.
You say it cannot be implemented as extention?
Then I see reasons for handling interleaved channel
data, but you
probably already have that under LV2 or you can do that anyway, and
also handling an arbitrary number of inputs and outputs in the case of
a media player could be not worth the effort.
I dont think there is port type for interleaved channel data defined
yet. If someone really needs it nobody can stop him.
Then I have quite clear ideas about the GUI thing and,
guess what, I
think I'm going to do something similar to LADSPA XML GUI DTD, only
coded inside the plugin itself. It seems like that in this kind of
applications sound processing is not a central topic, so
auto-generated GUIs are acceptable, and they solve the GUI toolkit and
portability problems totally.
Why not apply this approach to LV2? Again, do you think media player authors would prefer
to fight with
extensions (and write some if something is missing) instead of writing
their own API and be happy with it?
Of course, if something is missing in EPAMP, that requires a new
version... and that's why I'm trying to talk with them already.
Using plugins in media players is brain dead idea, but if they want that
they have quite a lot of possibilities anyway. Using LV2 plugins through
helper library like slv2 is really easy.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>