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

[Stefano D'Angelo]

2008/6/2 Nedko Arnaudov <nedko at arnaudov.name>:
> "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.

As said, probably most biggest platforms have that. However I don't
see any reason to exclude little unknown platforms, since there can
easily be no OS-specific part in the core spec.

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

But you agree this is in contrast with the API?

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

Absolutely, in fact I know of no media player using them.

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

Well, so you're saying that LADSPA/LV2 are not for them?

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

No. I'm saying it can be done, but is very unnatural and overly complicated.

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

That's what I was saying already, but again: yet another extension.

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

I was referring to using extensions for things which could handled
done more easily by the host if using their own application-specific
API.

Anyway I'm not going to use XML files for that, but that XML GUI DTD
can be inspiring.

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

So, how many media players have that or are going to do that? I guess
numbers are not on your side. :-\

Stefano