2008/6/2 Paul Davis <paul(a)linuxaudiosystems.com>om>: [...] I shouldn't have answered, then, but I do recognize your invaluable work on many important projects like Ardour, JACK, etc., so I'm not going to ignore you as well. 1. I never claimed EPAMP is the result of extensive discussion about LADSPA or LV2 and their problems; 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...); 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. While you think I'm criticising LADSPA/LV2, I'm not. Otherwise, why should I use them as a model? EPAMP is an attempt of "regulation" of a niche of software where application-specific APIs are quite dominant. Those people, for a reason or another, chose not to use LADSPA/LV2, and I think they have their own reasons. Can you really be against such an effort? I never said it is completed and discussion is closed, it is work in progress as stated at the beginning of such draft. You can read in the previous mail that I'm trying to contact a lot of people to "have feedback", not to do spamming. It is not final and/or completed. 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. And why should I reference GStreamer? Only because the projects are "similar" (which is absolutely not true)? Then if you read the "About" page: "[...] it is to sound processing components like what GStreamer is to audio/video files or Imlib2 to image files [...]" Not an exact reference of course, but that is divulgative stuff after all (and you were probably meaning something else also, I guess). No, I was not aware of that, and sincerely I'm nor afraid neither worried now that I know. Then again, reading before criticising without a clue could be good for everyone: http://naspro.atheme.org/content/overview-approach-taken However, I see no problem in me trying to do that. Since this stuff is about interoperability, if I succed it's good for everyone, if I fail nothing bad happens and you can see where I did wrong. The same holds true for EPAMP: since I'm going to support it in NASPRO, probably in the next release, LADSPA hosts will be able to load and use such plugins through it without touching a single line of code. The same will happen with LV2 hosts when I'll add support for LV2. 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. 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. 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). Best regards, Stefano

Hi Nedko, 2008/6/2 Nedko Arnaudov <nedko(a)arnaudov.name>me>: 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... 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?) 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? 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. 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. See above. This mail was for EPAMP and not NASPRO. NASPRO will work without host support (I have to update the docs) and there will be LV2-to-NASPRO and possibly NASPRO-to-LV2 bridges (non exact definition, just colloquial speech), so they're not against each other ;-) Then LV2 has the strategic position of being extendable, which means we could develop together stuff which is an extension to LV2 and a new layer to NASPRO. Wouldn't it be cool? 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. Come on, I'm almost always on #lad ;-) Cheers, Stefano

HI Arnold, 2008/6/2 Arnold Krille <arnold(a)arnoldarts.de>de>: Ok, so it could look like this: set LV2_PATH="C:\Program Files\LV2:D::E:" Understandable, but IIRC the "unwritten convention" for Windows is to use semicolons. Then I read that on Mac OS classic, colons are path separators (I don't know, never used it). Of course. Stefano

"Stefano D'Angelo" &lt;zanga.mail(a)gmail.com&gt; writes: Windows has DllMain() instead. I bet nobody will complain if Windows developer requests to extend the documentation with using semicolons instead on Windows. VSTs are much more complex IMHO you should compare XMMS plugins to GSteamer plugins, really... You say it cannot be implemented as extention? I dont think there is port type for interleaved channel data defined yet. If someone really needs it nobody can stop him. where? complexity? I wouldnt call XML GUI DTD simple... 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>

Hallo! I think that's a good point, but IMHO the solution is not to just invent the next plugin standard. Everything you need can be done with LV2 plugins, although you might need a new extension. However, if we wish that many media players will support an effect plugin API, then an easy to use library must be implemented and well distributed, which supports all needed lv2 extensions you want, so that writing an LV2 hosts becomes a really easy thing. So I appreciate very much your attempt for creating a common, easy to use API. However, IMHO the answer should be to extended and distribute LV2 so that it supports all your needs - then all efforts would be combined ... Well, there exist many methods for spatialization (you could also think about ambisonic and other techniques) - it's not likely that a simple media player will implement all of them ... LG Georg

Hallo! Of course it's not simple, but there exist already the slv2 library (sorry if you know it already): http://wiki.drobilla.net/SLV2 Lars Luthman made also a nice C++ wrapper, so that writing plugins is really easy: http://ll-plugins.nongnu.org/lv2pftci Some weeks ago there was also a discussion on how to make general GUIs which work also in non-GTK hosts (see the thread: [LAU] Ideas for LV2). Such helper-tools are needed IMHO and of course they should also run cross platform and support different compilers ... I guess they appreciate very much any contribution - they are only a little bit grumpy if someone proposes a new plugin API ... ;) Yes, but if these plugins would be easy to use, then it would be a real killer feature for every media player ... :) LG Georg

"Stefano D'Angelo" &lt;zanga.mail(a)gmail.com&gt; writes: 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 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. 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. Yup, you got the spirit of LV2 extension evolution :) 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. 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>

On Mon, 02 Jun 2008 17:57:46 +0200 Lars Luthman &lt;lars.luthman(a)gmail.com&gt; wrote: Traverso is cross-plattform and supports lv2, however, I don't know if it supports lv2 on windows and I can't test it. Remon should know. mfg Philipp

I don't want to get too much into the details, but I would like to say that I can at least see what Stefano is getting at here. This is an API for applications that don't want to have to think hard about plugins -- they just take the data from a file, blat it through a series of almost identical black boxes, and stream it to the audio driver. Why not do that with LADSPA (or LV2 or VST or whatever)? Because there are too many routing possibilities, too many plugins, and too many parameters. It's not easy to anticipate the ideal environment for any given plugin. Your application would either be overloaded with possibilities for the user to resolve, or else you would end up effectively hardcoding a known set of plugins and parameters. The available plugins would likely prove a poor fit for the application, and the ability to take advantage of new plugins and features would be reduced. You would have gone out of your way (in terms of understanding the design of the API, working out how to make it conform to your platform requirements, bringing in any necessary support libraries such as for RDF, etc) to do something that eventually produced a less effective result than copying and pasting an existing algorithm. Most programmers don't take all that much persuading that it would be "simpler to roll your own". Also, an API like LADSPA is designed on the basis of trying to make the plugin author's life as simple as possible at the expense of the host author. For better or worse, the field of media players is one in which hosts are almost as numerous as plugins, and making the host harder to write is much less likely to be a good strategy. I think Stefano is running into a classic sort of resistance here which says that you already can do it a certain way _technically_, and the rest is just _cultural_, and the cultural stuff doesn't matter. But it does matter. So I can see where this is coming from. The problem of course is when it turns out that your cultural differences have concrete technical causes -- such as in the stereo-to-5.1-conversion example. It may be that bridging some of the cultural divide through, for example, appropriate metadata for an LV2 plugin reaps more benefit in the end than trying to start again and approach this as if it were a completely separate problem. Supporting RDF metadata for tracks is becoming a more interesting idea for a media player anyway, so some of the infrastructure can presumably be shared. Chris