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

[Nedko Arnaudov]

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

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

If shared object format used by "little unknown platofrms" has no way to
do global init/uninit, what could lv2 do for you? And after all, why you
need that at all? I do use global initialization in zyn, but I would
call that code universal, thus suitable for inclusion in lv2core

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

I know at least one player that uses LADSPA for sure, aqualung. However,
plugin format as any other software is often shaped to meet user's
requirements. And those requirements tend to be slightly different for
music creators and music consumers. From this POV, I'd like LV2 to suit
music creators needs, still I personally dont mind if it is also
suitable for music consumers needs.

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

Software *is* unnatural, it does not exist in nature ;)
Also you are doing subjective claims for problems. Objective
problems need to be explained so they could be solved.

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

Yup, you got the spirit of LV2 extension evolution :)

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

Some other people tend to mix core LV2 functionality with extension
functionality too. Especially SLV2 has built in support for UI
extension. IMHO, there is nothing wrong with such approach, still i
prefer separate helper functionality for separate extensions. I.e. I
prefer bazaar evolution over cathedral dictate.

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

That was my personal POV, as I already said, helper libraries like SLV2
should bring LV2 adoption really easy for any media player authors, if
they want their app to use LV2 plugins.

-- 
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/7b2d7dd2/attachment.pgp>