2 Jun
2008
2 Jun
'08
1:06 a.m.
2008/6/2 Paul Davis <paul(a)linuxaudiosystems.com>om>:
[...]
I'm not interested, and I do want to start a flame
war, and I won't
ignore you.
I shouldn't have answered, then, but I do recognize your invaluable
work on many important projects like Ardour, JACK, etc., so I'm not
going to ignore you as well.
One of the most irritating things in the open source
community is not
when people come along and (constantly) reinvent the wheel. No, thats
actually probably a good thing if its done the right way. The irritating
thing is when people propose replacements for Foo without once
explaining what was actually wrong with Foo. It gets even worse when the
people responsible for Foo have themselves identified a lot of things
wrong with it, and have themselves offered up Bar as a result of
extensive discussions about Foo and its problems.
1. I never claimed EPAMP is the result of extensive discussion about
LADSPA or LV2 and their problems;
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...);
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.
There is nothing in your draft document that offers up
substantive
critique of LV2 (or even LADSPA). You make no reference to GStreamer, a
project which overlaps with many of your goals. You mumble about the
"user interface part is missing" almost as if its an afterthought, when
in reality, this has been the single most problematic part of any audio
processing API for Linux and other X11 based platforms. Its not just
some detail you can tack on, its an absolutely central part of the
problem. You also make grand, sweeping claims for NASPRO:
"Its main aim is to give audio application developers a full-featured,
yet scalable, high-performance and integrated tool to make use of
virtually any external sound processing component (including, but not
limited to, LADSPA/DSSI, LV2, VST, AudioUnits and DirectX plugins) via a
single, fully transparent and platform-independent API."
While you think I'm criticising LADSPA/LV2, I'm not. Otherwise, why
should I use them as a model?
EPAMP is an attempt of "regulation" of a niche of software where
application-specific APIs are quite dominant. Those people, for a
reason or another, chose not to use LADSPA/LV2, and I think they have
their own reasons. Can you really be against such an effort?
I never said it is completed and discussion is closed, it is work in
progress as stated at the beginning of such draft. You can read in the
previous mail that I'm trying to contact a lot of people to "have
feedback", not to do spamming. It is not final and/or completed.
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.
And why should I reference GStreamer? Only because the projects are
"similar" (which is absolutely not true)? Then if you read the
"About"
page:
"[...] it is to sound processing components like what GStreamer is to
audio/video files or Imlib2 to image files [...]"
Not an exact reference of course, but that is divulgative stuff after
all (and you were probably meaning something else also, I guess).
apparently unaware that this goal has (a) eluded
almost all other
attempts to do the same and that (b) where such efforts have succeeded,
getting it right and making it work has been a full time *paid* job for
several reasonably well-paid and very smart software developers (e.g.
FXpansion's AU/DX/VST bridge systems). you also seem unaware that there
is already a working group of plugin developers from the VST, AudioUnits
and DX worlds attempting to do precisely what you describe, and that
whatever they come up (if they come up with anything), its likely to
carry a lot more weight among the world of plugin developers worldwide.
No, I was not aware of that, and sincerely I'm nor afraid neither
worried now that I know.
Then again, reading before criticising without a clue could be good
for everyone: http://naspro.atheme.org/content/overview-approach-taken
However, I see no problem in me trying to do that. Since this stuff is
about interoperability, if I succed it's good for everyone, if I fail
nothing bad happens and you can see where I did wrong.
The same holds true for EPAMP: since I'm going to support it in
NASPRO, probably in the next release, LADSPA hosts will be able to
load and use such plugins through it without touching a single line of
code. The same will happen with LV2 hosts when I'll add support for
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.
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).
Best regards,
Stefano