2 Jun
2008
2 Jun
'08
8:12 a.m.
Hi Nedko,
2008/6/2 Nedko Arnaudov <nedko(a)arnaudov.name>me>:
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.
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?
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.
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.
See above.
Why would those people use NASPRO instead of LV2?
This mail was for EPAMP and not NASPRO. NASPRO will work without host
support (I have to update the docs) and there will be LV2-to-NASPRO
and possibly NASPRO-to-LV2 bridges (non exact definition, just
colloquial speech), so they're not against each other ;-)
Then LV2 has the strategic position of being extendable, which means
we could develop together stuff which is an extension to LV2 and a new
layer to NASPRO. Wouldn't it be cool?
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.
Come on, I'm almost always on #lad ;-)
Cheers,
Stefano
"Stefano D'Angelo"
<zanga.mail(a)gmail.com> writes:
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?)
2. There's nothing wrong with LADSPA or LV2,
and they are already
being used by media players in some cases, but you should be honest
with yourself and everyone else about a couple of things for the
benefit of everyone:
a. APIs which are written and meant to be used only on UNIX-like
operating systems and contain no indication for any other platform are
not that great for cross-platform use, which is quite common practice
among media players (I know there are exceptions like Audacity using
LADSPA plugins on Windows, but...);
There is nothing wrong with using LV2 (and probably LADSPA too) on
non-UNIX platforms. 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. 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? so please, go ahead and invent us a better wheel. but
first, show us
that you understand what's wrong with the old one, that you've seen the
efforts to fix it, that you understand the problems with them too, and
then explain clearly how your proposals fix both sets of problems.
I repeat, the problem is that those people are not likely to use
LADSPA/LV2 ever, and have their reasons to do so. I started from
something which looks like LADSPA/LV2 but has already some new
features. Now I'm collecting ideas from them in order to shape the
whole thing around their needs. If you want to
know (secrecy has never been part of F/OSS AFAIK)
here's a list of suggestions I already received:
- effects could have some value associated to them indicating the
extra-delay time their algorithms introduce due to use of "future
samples" (think about video/audio syncing);
- effects could have a group of standardized parameters which the host
understands and can control more flexibly (for example "quality vs.
speed");
- at least one system wide compile time plugin path would help on
UNIX-like systems (pkg-config could be used);
- UI controls should be kind of separated from the data type of a
parameter (for example, an integer parameter can be on a scale, a
choice with radio buttons, etc.);
- logical grouping of UI controls which have affinity.
Why you think this features are out of LV2 domain? Are you sure they are
not already addressed in some form in a LV2 extension? Now, I
seriously want to say that I am more than willing to cooperate
with you if you want (and I will bother some of you even if you don't
want I guess), especially now that we have an extensible API like LV2.
Our objectives are the same after all (I guess).
This is nice of course :)