2 Jun
2008
2 Jun
'08
12:57 p.m.
"Stefano D'Angelo" <zanga.mail(a)gmail.com> writes:
VSTs are much more complex IMHO
Absolutely, in fact I know of no media player using them.
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.
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.
That's what I was saying already, but again: yet another extension.
Yup, you got the spirit of LV2 extension evolution :)
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.
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>
2008/6/2 Nedko Arnaudov <nedko(a)arnaudov.name>me>:
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
"Stefano D'Angelo"
<zanga.mail(a)gmail.com> writes:
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. 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... > 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?
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. 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.