2 Jun
2008
2 Jun
'08
2:58 a.m.
"Stefano D'Angelo" <zanga.mail(a)gmail.com> writes:
Why would those people use NASPRO instead of LV2?
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 :)
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>