Hi All, On Wed, 28 Oct 2009, Nedko Arnaudov wrote: I didn't know about NASPRO. Thanks! And thanks to everyone who has (and will) comment. -gabriel

2009/10/28 Jörn Nettingsmeier <nettings(a)folkwang-hochschule.de>de>: Also there should be two full-packages: lv2-sdk (everything required to start development, including extensions and libs, slv2, docu, etc) lv2-plugins-all (the most used/recommendable, stable plugins, ready to run, incl. dependencies) Gathering the required packages and dependencies for plugins and hosts (with corresponding versions ! ) is a kind of detectiv work currently. -- E.R.

On Wed, 2009-10-28 at 16:59 +0100, Jörn Nettingsmeier wrote: Implementing an LV2 with the same capability is every bit as easy. Like many complaints about LV2, this really just amounts to whining that someone else hasn't done everything for you already. That's not a failure of community engineering, that's a shortage of time and people to actually do the work. This is hardly a new thing in LAD. There are simply not that many developers around, and things take time. LV2 now is a lot more powerful than LV2 when the spec first came out, and LV2 a year from now will be a lot more powerful than it is now. If you think LV2 "was" (?) a spectacular failure, you clearly aren't really paying attention. "Failure"? Why, exactly? The extension approach IS community engineering. It allows YOU, or anyone else, to actually do the work. A monolithic specification just results in an endless war on mailing lists, and allows NOBODY to actually do the work. (*** If you read nothing else in this email, read this ***) Blaming the mechanism for this is complete nonsense (and people trolling and spreading FUD by doing so has gotten /really/ old). This is exactly like blaming the shared library mechanism for the fact that there's no open source shared library to do realtime granular resynthesis, or whatever. Think about how absurd this is! Would you start sending emails to your OS distributor because there are no shared libraries for realtime granular resynthesis, because their "shared library" pie in the sky technology somehow prevented it from being done? Of course not, that's completely ridiculous! The mechanism is what makes it possible to implement such a thing. Does complaining about the shared library mechanism in this way sound really stupid? It should. Complaining about the LV2 extension mechanism for a lack of implemented extensions is exactly the same thing. The problem is simply that NOBODY HAS WRITTEN IT YET. Enough with the FUD, please. The only thing really lacking in terms of community/PR IMO is the website, which is static, stagnant, and not particularly good anyway. It should probably be nuked and either everything moved to the wiki, or replaced with a CMS. The former is easier since there's already a wiki, the latter is fancier and more professional looking. Let's indeed. Feel free to get started any time now ;) Though there's not really a need to try and do this "canonically". What's 'clearly necessary' for one plugin is completely useless for another. An extension is supported or it isn't, in the vast majority of cases the plugin/host can easily just not use if it isn't there. The only real potential problem is when multiple extensions get created for the same thing. As long as people cooperate (via the mailing list and/or wiki) and create high quality extensions this should not be a problem. -dr

On Sat, 2009-10-31 at 17:35 +0100, fons(a)kokkinizita.net wrote: You don't need to extend the extension mechanism first (I don't even know what this means...) or write a new host either. Shared library, you get a thing by filename, it has code in it. Extension, you get a thing by URI, it has code in it. It is not "very different" at all. -dr

On Sat, 2009-10-31 at 14:05 -0400, Paul Davis wrote: There is a pervasive theme of people criticizing what they do not understand here. It is generally not wise to do that ;) Free, since this is all (likely) taking place in memory anyway. Identical. There is no other side of the equation because the whole thing is so painfully simply. You get your pointer. Done. They are both literally just mechanisms to get a pointer to some code/data by name. It's really quite simple... I'm not sure where this conception that there's some kind of hard to understand complex mechanism involved here comes from, but there really isn't at all. "Mechanism" isn't even an appropriate word, really, it's just a function. It's as straightforward as straightforward can be. Look at the header: const void* (*extension_data)(const char * uri); This is the "extension mechanism" for plugins. You give it a URI, it gives you something back. That's it. Implementing, and calling, such a thing is obviously trivial. The opposite case for adding stuff for the host to provide for the plugin is similar. Best practice is to return a struct filled with function pointers (so things can be added to it without breakage). In slightly higher level terms, what this allows you to do is add whatever functions you want to any plugin, in a very easy and straightforward manner with no bureaucratic overhead or anything else getting in your way. Not actually documenting things is obviously foolish, but feel free, just like shared libraries. How can this mechanism possibly be to blame for things not being implemented? There's virtually no overhead whatsoever to getting the job done, that's the entire point! Again, this lets you very easily add whatever functions to a plugin you want. There is no voodoo here. I am not obscuring any details, or anything like that. That's really it. You can add whatever you want, extremely easily. Blaming the extension mechanism for such and such not being implemented is every bit as nonsensical as blaming the shared library mechanism for the same. You can easily write whatever functions you want, in either case. -dr

On Sat, 2009-10-31 at 15:32 -0400, Paul Davis wrote: Fine and good. Except that's not what's usually said, and that's not what was initially said here. LV2 is, apparently, a "catastrophic failure". When it's not that, it's usually FUD or misinformation about the extension idea itself. Excuses and whining, not arguments and solutions. I agree there is a difference, and more of the latter would be nice. This is true, but inherent. You get one, and only one of the following: - LV2 as it is currently, and the ability to solve this problem (and the eventual outcome that they all get solved) and increase the power of the whole thing - Nothing at all You are free to use GMPI if the latter option sounds appealing :) There is nothing magical about API defined in an extension as opposed to "LV2". If LV2 was a monolithic specification - well, it wouldn't actually exist in any finished or usable state at all, but let's make that huge leap and pretend it is - then this same situation would exist. Feature foo needs to be implemented by a host regardless. The difference is, with a monolithic specification feature foo not being implemented by the host means that host doesn't support anything LV2, at all, whatsoever, end of story. This is clearly inferior. It requires interactions, but I don't really agree it requires anything new at all, certainly not in this community. Libraries or plugins, their interfaces, and the programs that implement/use them always co-evolve. Of course they do, they either co-evolve or do not evolve whatsoever and die. It's no different than if it was all crammed into one kitchen sink specification, then everything still needs to co-evolve in the same way except the barriers to doing so are MUCH greater, to the point of basically preventing any evolution whatsoever (a textbook outcome of bad, non-modular design). Some people get this, but others just point at the whole thing and whine, and do nothing. The reasons are purely psychological, not technical - they don't want to help, and blaming others and the technology is easier. It is a childish attitude bred by people being accustomed to gigantic soulless corporations telling them what to do, in my opinion. It has no place here. In the vast majority of cases, an extension not being supported means the plugin will work fine but that functionality isn't present in the host. For example, a command line host may not support GUIs, so the GUI doesn't work. I don't think this is really all that complicated for a user to understand, or a problem: a program simply doesn't support GUIs. It's not like a user has to sit down and enumerate and cross reference these things or something. It has been designed to gracefully degrade for exactly this reason. Maybe. If he didn't get all trolley and call the whole thing a catastrophic failure then maybe I would have focused on that part ;) Arguments about this at a high level are almost entirely pointless anyway: developers who are actually going to solve the problems will show up and do so. The kind of people who whine on mailing lists about it or make up sociological arguments for the lack of this and that aren't the sort of people who are actually about do it anyway, so who cares what they think? What could actually be done to magically make people show up who will do this work? Nothing. A developer who is interested in making e.g. ramped control ports will show up, or they won't. The whole thing simply has to grow, which is the only realistic way to solve a problem like this anyway. How about this: just pretend LV2 IS a monolithic specification! Therefore, it does not exist in a finished state yet (just as it wouldn't), and there is no such thing as LV2. There is no technological difference between this and reality. If you want to define "the LV2 specification" in your mind as some bloated and completely arbitrary kitchen sink of features, feel free to do so and consider the entire thing unfinished and not worthy of implementation at all. Call extensions "working groups" or whatever to satisfy your bureaucratic leanings. Is this stupid? Sure it is. But that's basically my point :) Obviously I agree things need to be done, but whining about the entire thing at the meta level is not what needs to be done. Extensions are (well, should be) tidy little bits of well-defined functionality. When there is a hole, as you said, you make one, you implement it, and the problem is solved. As people scratch those itches, all the problems will be solved. Itch scratching solves problems, FUD and whining doesn't. Itch scratching is pretty much the ONLY thing that solves problems around here anyway. LV2 is simply optimized to exploit this fact of reality as efficiently as possible, and it's worked pretty well so far. There is no committee to point fingers at, because you can implement whatever you like. The only place to point that finger is at yourself. This way, things get designed and implemented by people who actually give a damn about those things. The end result is quality software. Calling the whole thing a catastrophic failure is, frankly, complete and utter bullshit, and spreading that kind of opinion only HURTS progress. Someone may skim through the list, see that, and decide that LV2 is a failure and thus not worth investing in or implementing, which is completely untrue (and happens). I call it FUD for a reason, it damages LV2 in exactly the same way a certain notorious company damages others with FUD. People not actively helping doesn't really irk me so much - but people doing this certainly does. LV2 is no failure, but keep sabotaging it in that way and maybe it will be. Pointing out that the community engineering aspect is a failure and then doing precisely the thing that damages it the most is a teeny bit hypocritical, isn't it? There is no inherent problem with LV2, there are only jobs to do - and they will get done, eventually. Most likely by people who spend more time typing into their text editors than their email clients. End of story. -dr

On Sun, 1 Nov 2009, Patrick Shirkey wrote: Doesn't VST do it through branding? VST is for effects, VSTi for instruments (softsynths), etc.? Perhaps LV2 could do a similar sort of branding... with the name defined by the extension. E.g.... LV2-fx LV2-synth Bonus points if some manner of logo integration could be done, too. Standardizing how this is done would make it easier for application developers and users to understand. -gabriel

On Sat, Oct 31, 2009 at 9:09 PM, Patrick Shirkey &lt;pshirkey(a)boosthardware.com&gt; wrote: [ ... stuff .... ] the idea occured to me sometime today. "my host supports LV2-E1" "my plugin requires LV2-E2" "this application uses LV2-E<N>" EV<N> = LV2 core + { extA, extB, extC .. } its not a new idea, i'm just "naming" it.

2009/11/1 Patrick Shirkey &lt;pshirkey(a)boosthardware.com&gt;om>: To me this is nonsense, the best way to do that I can imagine is assigning one bit position to each extension and sum them up to give your <N>, but I can already imagine huge unreadable numbers (how many extensions do we have now? 20?) and probably there's no better way to do that. This also clashes IMO with the idea of using URIs for decentralized extension development (no, please, not unique ids again!) Anyway, this sounds as a really marginal thing to me... but maybe it's not? Regards, Stefano

2009/11/1 Paul Davis &lt;paul(a)linuxaudiosystems.com&gt;om>: Sorry, I didn't really get what you were meaning then. In this case it's surely possible, but would it really be much more "readable" to use a number than to state the name of such extensions or, even better, define sets of extensions as "levels"? I mean, 10 extensions means numbers from 0 to 1023, and you have to know binary arithmetics to make sense of which extensions are supported... not very marketing friendly. Better to define "level 1", "level 2", etc. IMO. Anyway, since this does not affect LV2 as a specification, I just really don't care. The one thing I would care about is how/which extensions would belong to a certain standard/set, etc. Best regards, Stefano

On Sun, 1 Nov 2009, Paul Davis wrote: So... something like this? LV2-EBasic := LV2 core + URI Map + MIDI Event LV2-EPlus := LV2-EBasic + External UI LV2-EExtreme := LV2-EPlus + dynparam + Progress LV2-EVideo := LV2-EBasic + SMTP + Transport Note: Yes, I know some of those extensions don't exist or are proposals. Some may not even relate. I'm still trying to understand it. :-) BTW: Some of the extension API's seem more like plumbing. Resources for communicating between plugins. Things that have little relevence to the end user. For example, the URI Map seems like it's just a utility for an extension or a plugin -- but the host doesn't necc. need to add support for it. Is this right? Peace, Gabriel

On Sun, 2009-11-01 at 10:10 -0400, Paul Davis wrote: What problem does this solve? The functionality itself is defined in terms of specific features. Host and plugin authors can talk about support for "the transport extension", or whatever, as they do now. Is there any real point to this other than blind VST emulation? I don't think it has ever once come up that someone needs to talk about some specific large set of extensions as a whole and it's tedious to enumerate them all, or whatever. This kind of effort is mostly a time sink for people who are powerfully inclined to making baroque categorizations for everything. It seems to be an almost religious fervor with some people (who should never be let within 100 feet of a design document), I find the whole thing really kind of amazing. Anyway! More concretely, the reasons this is silly are obvious if you think about it. There is simply no such categorization. Blahrdour likes "effects" and "synths", can support "presets", has a concept of "transport". Blingen likes "effects" and "synths" as well, can support "presets", has no concept of "transport". Which category does "transport" go into, then? It's not really related to any of the other things at all, it's a completely independent feature. This is true of most extensions. Even if one came up with such a baroque categorization, it would be worthess, because the number of exceptions would pretty much the same as the number of supported things anyway. Pretending that everything would fit into these nice little boxes to support the effort is silly - they won't. Now, that said, there is ONE such "standard" that I do support - namely extensions that have been peer-reviewed (on the lv2 dev mailing list), accepted by consensus, and implemented by at least 2 plugins and hosts (this is already the consensus on what gets to have a http://lv2plug.in URI). This is definitely a good idea, and if someone wants to come up with a fancy name for it, feel free. Multiple categorizations is a fool's errand, but making clear what the community has taken a good look at and accepted, and what's just some random kludgey thing patching a hole for somebody in the short term, is definitely a high priority goal. -dr

On Sun, 1 Nov 2009, David Robillard wrote: Yes and No. Manufacturers are required to publish their MIDI Implementation so that the person buying the device would know what types of MIDI messages the device sends and responds to. This includes the summarized table and the down-to-each-sysex-bit documentation. If you know you want an MMC-capable device, you know to look here. If you don't want to do LV2-EXtremeMakeover-HomeEdition or LV2-El33t, then perhaps a concise table with a standardized format might work better for you. Or even a just a standardized way of saying it. Something more clear and concise than "Foomatic-LV2 depends on the URI Map extension and the MIDI Ports extension [exactly /who/ is supposed to supply these?]. And, oh yeah, we forgot to tell you about the dynparam extension... but I'm sure you'll figure that out when things don't work." -gabriel

On 11/02/2009 05:41 AM, David Robillard wrote: That's the funny thing about this discussion. I feel that if you say it is useful but slightly unnecessary then for a lot of people it will be extremely useful :-) FWIW, I will try to bring this information out in a simple manner on the wiki. If anyone has the time to think of a detailed method for handling this please share. I will need a more advanced description of how it needs to be executed and displayed to implement this quickly. Is this method clearly defined in the online docs? Patrick Shirkey Boost Hardware Ltd

On 11/02/2009 08:06 AM, David Robillard wrote: This will be a priority for me. This will be a core function of the plugins site. This information can be brought out into a more prominent location for all the documentation. Patrick Shirkey Boost Hardware Ltd

On Mon, 2009-11-02 at 19:37 +1100, Patrick Shirkey wrote: Bah. Do we even want people around with such a large stick up their ass as to take this seriously? :) The Dummies books are one of the best selling book series ever. An overly well documentated example/stub plugin would be best for this, IMO, since it doubles as an example they can modify to make a real working plugin. Don't get too caught up in the importance of external documentation - people generally only read it as a last resort. People are far, far more inclined to work from examples - combining the two is the best of both worlds. The bundle can also have a makefile (or whatever) to generate documentation and such, with the side-effect that people who base their plugins off of that bundle automatically Get It Right. There are too many variables in implementing a host to do this, to be honest, and explaining how to do it without a library will probably scare people away more than anything (you need to query an RDF document, for starters...). This is why slv2 exists. I don't pitch it as "necessary" or "standard" (it isn't) since I wrote it, but I don't think every host reimplementing e.g. plugin discovery is a very good idea at all - it's likely they'll get it wrong. That kind of stuff should, without a doubt, be implemented in a library. This way everything works consistently, the same environment variables are obeyed, the same plugins are discovered, etc. I doubt there are people capable of writing a host for whom http://drobilla.net/docs/slv2/ (or the equivalent man pages) isn't enough information to get off the ground. Focus for this kind of thing should definitely be mostly at potential plugin authors, IMO. There are far fewer (potential) hosts, and they're more complicated, and typically headed by someone who knows what they're doing anyway. Documentation efforts should be focused at the casual weekend developer type who might actually come along and read the docs, determine it's easy, and write a plugin or two. They're not so likely to write a DAW :) -dr

On Sun, Nov 1, 2009 at 12:14 PM, David Robillard &lt;dave(a)drobilla.net&gt; wrote: specifically *not* the entire extension ecosystem. subsets of the ecosystem that can be named, referenced, referred to, *developed against* by plugin/host authors, with some expectations. when you give examples from the web, i think there is an interesting lesson there. people with an interest in extending "html" in some way (e.g. embedded svg, theora, whatever) know what the path is: develop the technology/specs/etc, get some initial implementations, push toward w3c ... adoption by w3c (if you're lucky). a similar path exists for LV2 except for the last part. you can argue that its the cart before the horse - develop the stuff first, then lets argue about how its to be part of a named "ensemble" or "standard" or whatever. but i would contend that part of the reason for a reluctance to develop (which you pointedly referenced) is the lack of any clue what happens *after* that. you know, its great that LV2 lets anyone and their mom define a cool new way to do ramped plugin parameter control. but so what? how is that of any interest to someone who wants to figure out, not just a technical solution to the issue, but an accepted, in-use engineering solution? if the pathway to the second part isn't clear, the first part is less likely to get done. with LADSPA, it was very easy to motivate discussions about design changes - there was one header, and it got into the header, or it didn't. its similarly easy, when necessary, to do the same for JACK - once again, there is one header, one API and something is either in or out, or modified. LV2's glorious anarchy means that there is no social necessity for any convergent effort at all. people can do whatever the hell they want (good!) and nobody else need care (bad!). ok, so people don't agree yet on how to do plugin API feature X ... then we need a mechanism that does more to force us to actually come up with solutions. LV2 doesn't do anything to force this, possibly by design. its no suprise, therefore, that people who might feel a pressing need for this or that don't do anything about it, because its not actually clear to them that it will be a "solution" at all.

On Sun, 2009-11-01 at 12:09 +1100, Patrick Shirkey wrote: This is definitely true, the site and documentation needs work. Making things like "LV2-fx", whatever the would be though, is pointless. There would be too many of them, what gets in and what doesn't would be just a big silly debate with no point. Most features apply equally to both anyway. "Features" are not difficult for users to understand! VSTi vs VST is basically just a product of VST being crap :) The only difference between a "synth" and an "fx" plugin in LV2 is one happens to have a MIDI port, and probably a certain plugin category under "Instruments", etc. It really doesn't mean much at all. The volume isn't really big enough for this, to be honest. We can set up an RSS feed or something, or an announce list, but I really don't see this as being an effective thing to worry about at this point in time. You'd be automating nothing. Need an actual nice presentation for extensions first, before announcing matters. The mailing list is low volume enough that any developers interested in LV2 goins-on should simply be on that. I'll look into adding RSS to my documentation generator thingie though, that's kind of a cool idea. Awesome, thanks. I think the main problem right now is that the site is stagnant. I think maybe the most feasible path, effort wise, would be just to move all the content over to the Wiki, which is easy for everyone to participate with, and nuke the site. I could probably get Steve to install Drupal or Wordpress and make a bit more of a "professional" looking site that way, but it's more work, and then we have two account systems instead of one. Is there any advantage to this beyond pretty? Seems no, and adding content is a bit more tedious. So maybe the best housekeepingey thing to do right now is get all the content over to the wiki, and tidy up the wiki, then we can make it the main page for http://lv2plug.in ? Cheers, -dr

On Mon, 2009-11-02 at 07:10 +1100, Patrick Shirkey wrote: Isn't this basically what LAA is for anyway? At the end of the day the author of <whatever> needs to send the announcement to /somewhere/, you can't automate news generation, it has to come from people somehow. The fully automated thing is feasible for extensions published at http://lv2plug.in/ but not much else. This is an argument for using a CMS over a wiki though. It's easy to make an RSS feed of a 'news' page and tag posts to go there. With a wiki, not so much. The only real options are wordpress and drupal since they are trivial to install on Dreamhost. Don't start until we're sure this is the best plan. It's not really feasible to do the above stuff via mediawiki. -dr

On Mon, 2009-11-02 at 08:34 +1100, Patrick Shirkey wrote: Probably by modifying http://drobilla.net/software/lv2specgen/ to generate an RSS feed as well. IMO this would probably be better off implemented as a separate script or something that has nothing to do with the CMS, so it is useful elsewhere and not tried to drupal. -dr

David Robillard wrote: <many, many things> dave, if you'd really read the my post in its entirety and not jumped at the one provocative catchphrase, you might have noticed that we're pretty much on the same side. heck, i've even begun to dig into larsl's lv2 tutorial. to re-iterate what i had thought i had been communicating: lv2 is a *very* *sexy* piece of *software* *engineering*. the problem is, many people are looking for a *standard*. as a standard, lv2 is ages behind ladspa, because you just don't know what your host will support until a canonical set of extensions has emerged and is generally implemented. don't give me that graceful degradation thing - if a plugin author wants an extension, it's generally mission-critical and the plugin will be unusable except in those few carefully crafted examples you gave. let me dig out the tired old analogy: lv2 is xml. you can define what you need, and anything goes. in principle. ladspa is html. it's ugly, kludgy, non-extensible. but if i put something in <a></a>, then every friggin browser in the world will underline it in blue and make it perform the action the user expects when she clicks on it. that's quite lame from a software architecture standpoint, but it's really cool for users. i'll be the first to admit that my programming skills are more akin to a html "programmer" than anything real. i can write a ladspa plugin in no time. i could also write a simple ladspa-equivalent lv2 plugin in no time, but using all those cool extensions or probably designing my own is beyond me. hence, no win, and no inclination to pick up lv2. world domination implies you gotta win at least a percentage of the dumb fucks like me, not just the hotshots. please, dig this: i'm talking about the standards aspect, not the engineering aspect. i don't know shit about software engineering, and never claimed otherwise. however, i do know which things pick up momentum and which linger half-dead in the water. actually, the largest part of my post was about strategies to help lv2 pick up momentum. don't give me that M$ FUD shit, either. heck, i've been doing more linux audio advocacy in my life than is good for me, and i really don't see why you're perceiving a little provocative discourse as some sort of intrigue from evil incarnate. just relax. that said, i hope you know i appreciate and respect the work that went into lv2. hence, respectfully yours, jörn

David Robillard wrote: dave, "powerful" is about engineering quality. a standard (even if it is shoddily engineered) is good if i can adhere to it and be sure my stuff will work somewhere else. these issues are *orthogonal*. don't pee your pants, i'm not criticising the engineering part. what makes a standard successful is *market* *penetration* - everybody and their grandma implements ladspa because it's simple. implementing lv2 is harder. there are good reasons for it - it's better in every respect, except in uptake. there is an entrance barrier to it. you can ignore it and piss off people who point it out, but that's not going to remove it. ardour and other hosts frequently exploding in the presence of yet-unbeknownst lv2 features? yeah, in theory, they shouldn't do that :) or try to make sense of the swh gate plugin in the absence of epp:logarithmic... i'm not talking about mechanism. the mechanism is fine. i'm talking about the politics of getting a usable standard out there. the increased power of lv2 comes at the cost of greater complexity, which in return slows down the adoption. your definition of "plenty relaxed" seems to differ from mine quite substantially :-D the "standard" aspect of lv2 is not done yet. which is plainly evident from the fact that most innovative lv2 plugins that show up require patches to the host in order to work - it's not clear to host writers what they should implement, and plugin writers can't assume what will work in any given host. until that changes, lv2 is not a successful standard. and it takes other skills that software engineering to change that, which you seem to be a) unwilling to acknowledge and b) lacking. hence, i'd better give up now. how a person with arguably twice my iq can so painstakingly kepp missing the point i was trying to make is mystifying. but it seems pretty pointless to rehash it all over.

Dave, here are some observations I and probably many others made: 1) hosts are slow at picking up extensions <for some reason> 2) hosts mostly use just slv2 <for some reason> 3) plugin authors are reluctant to write extensions <for some reason> 4) a number of plugin authors wrote their own hosts <for some reason> Now people see different possible reasons for this, my version is: 1,2 -> I don't know. Bad documentation? Hard to use? 3 -> 1,2 4 -> 1,2 I think that's really all there is to this discussion, a bunch of observations, different interpretations of why this is and thus different suggestions to solve the problem. So what is your variant? Best regards, Philipp

On 11/02/2009 08:27 AM, David Robillard wrote: Isn't that the only reason for being a member of this list? I can see that the above details could be made more obvious to the casual developer. I will work on incorporating the details into the new documentation. I'm starting to get the impression that what is really missing is not just documentation but a complete documentation system. The average developer will be coming from a proprietary world where companies have invested a lot of effort to make the documentation accessible and in addition there are several external web projects offering to fill in the gaps as it can be a good little revenue earner with advertising and google ads, etc.. I don't have much experience with the specific plugin architectures and the developer documentation that is provided but perhaps others can make suggestions of the most useful documentation features they have found while developing for alternate plugin systems? However I have been working with borland, visual studio and xcode and found several common documentation themes in those environments that we are missing round here in general. Patrick Shirkey Boost Hardware Ltd

Maybe it is worth looking at the extension model used in OpenGL. Extensions are at first created as something vendor specific. Widely useful extensions get reviewed by the architecture review board and if deemed worthy become arb_extensions (this is now not essential to be implemented but highly reccomended). A lot of extensions eventually find there way into the core spec. Which means that vendors have to implemented them to be compatible with that version of the OpenGL specification. Another approach might be to compile a list of stable extensions that should be supported by a host. I would suggest that such a list would be compiled once a year and that lv2_[year] could be used to suggest if a host should be expected to support a particular extension. The time period could be longer if necessary. On Tue, Nov 3, 2009 at 1:08 AM, David Robillard &lt;dave(a)drobilla.net&gt; wrote: