Re: [LAD] [EPAMP] an effect plugin API for media players: anyone interested?

"Stefano D'Angelo" <zanga.mail@email-addr-hidden> writes:

> 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.

Why would those people use NASPRO instead of LV2?

> 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>

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev