"Stefano D'Angelo" <[EMAIL PROTECTED]> 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>
pgp0ddR6aJh2n.pgp
Description: PGP signature
_______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
