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

[Nedko Arnaudov]

"Stefano D'Angelo" <zanga.mail at gmail.com> writes:

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

Windows has DllMain() instead.

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

I bet nobody will complain if Windows developer requests to extend the
documentation with using semicolons instead on Windows.

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

VSTs are much more complex IMHO

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

you should compare XMMS plugins to GSteamer plugins, really...

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

You say it cannot be implemented as extention?

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

I dont think there is port type for interleaved channel data defined
yet. If someone really needs it nobody can stop him.

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

where? complexity? I wouldnt call XML GUI DTD simple...

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

Using plugins in media players is brain dead idea, but if they want that
they have quite a lot of possibilities anyway. Using LV2 plugins through
helper library like slv2 is really easy.

-- 
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20080602/0e061a68/attachment.pgp>