"Stefano D'Angelo" <[EMAIL PROTECTED]> writes: > 2. There's nothing wrong with LADSPA or LV2, and they are already > being used by media players in some cases, but you should be honest > with yourself and everyone else about a couple of things for the > benefit of everyone: > a. APIs which are written and meant to be used only on UNIX-like > operating systems and contain no indication for any other platform are > not that great for cross-platform use, which is quite common practice > among media players (I know there are exceptions like Audacity using > LADSPA plugins on Windows, but...);
There is nothing wrong with using LV2 (and probably LADSPA too) on non-UNIX platforms. > 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. > 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? >> so please, go ahead and invent us a better wheel. but first, show us >> that you understand what's wrong with the old one, that you've seen the >> efforts to fix it, that you understand the problems with them too, and >> then explain clearly how your proposals fix both sets of problems. > > I repeat, the problem is that those people are not likely to use > LADSPA/LV2 ever, and have their reasons to do so. I started from > something which looks like LADSPA/LV2 but has already some new > features. Now I'm collecting ideas from them in order to shape the > whole thing around their needs. Why would those people use NASPRO instead of LV2? > If you want to know (secrecy has never been part of F/OSS AFAIK) > here's a list of suggestions I already received: > - effects could have some value associated to them indicating the > extra-delay time their algorithms introduce due to use of "future > samples" (think about video/audio syncing); > - effects could have a group of standardized parameters which the host > understands and can control more flexibly (for example "quality vs. > speed"); > - at least one system wide compile time plugin path would help on > UNIX-like systems (pkg-config could be used); > - UI controls should be kind of separated from the data type of a > parameter (for example, an integer parameter can be on a scale, a > choice with radio buttons, etc.); > - logical grouping of UI controls which have affinity. Why you think this features are out of LV2 domain? Are you sure they are not already addressed in some form in a LV2 extension? > Now, I seriously want to say that I am more than willing to cooperate > with you if you want (and I will bother some of you even if you don't > want I guess), especially now that we have an extensible API like LV2. > Our objectives are the same after all (I guess). This is nice of course :) -- Nedko Arnaudov <GnuPG KeyID: DE1716B0>
pgpmxIHHls8Y7.pgp
Description: PGP signature
_______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
