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

Hi Nedko,

2008/6/2 Nedko Arnaudov <nedko@email-addr-hidden>:
> "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.

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

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

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.

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

See above.

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

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?

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

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.

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

Come on, I'm almost always on #lad ;-)

Cheers,

Stefano
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Mon Jun 2 16:15:01 2008