On Thu, Nov 05, 2009 at 01:18:53PM +1100, Patrick Shirkey wrote: The first part of Gordon's post is based on falsifyable claims, hence it is legitimate. The second part may be opinion, and no argumentation is provided, but still I see no reason to ban it. I have two questions to the LV2 consortium (by which I mean the group of developers actively advocating LV2). Q1. On the LV2 website, Lars Luthman's UI extension is described as: "This extension is written for revision 2 of the LV2 specification and is NOT compatible with revisions 3 and later. Do not implement this extension in new plugins or hosts, and do not expect it to work in old ones. It is only available here for archaeological purposes." Even in its short life LV2 has managed to create some archeology. So AFAICS, there is no GUI extension except the one using a separate process which does not really scale very well to large numbers of plugins (and which as Gordon already mentioned is provided in simpler form by DSSI). Which leads to my question: if everything can be done by extensions, as is the recurring mantra, why was whatever revision 3 provides not implemented as an extension to revision 2 ? Of course this would have led to the first example of two extensions being mutually incompatible, something which is a real risk but conveniently ignored in all LV2 propaganda. Q2. Would the LV2 consortium accept an extension that would: - if required by a plugin, be the only one, but unconditionally, - completely replace LV2's 'base', including the initialisation and process calls, the port descriptions in an external file, and whatever else by some other mechanism ? Such an extension would effectively embed a completely new plugin standard into LV2, leaving only the plugin discovery and packaging mechanism. Supporting it would be no more complex than supporting e.g. both dynparams and port groups, so there's no technical rationale for refusing such an extension. There could be an ideological one of course. But if that is enough to refuse an extension, then ideological attacks on LV2 are legitimate as well. Ciao, -- FA Io lo dico sempre: l'Italia è troppo stretta e lunga.

I'm pretty sure Fons is occasionally a very smart and effective troll ;) As a gedankenexperiment what are the problems in LV2 that make it ineffective or even inelegant for implementing something like Jconv i.e a wrapper on your very lovely zita-convolver? How should these be solved? Loki

On Thu, 05 Nov 2009 20:32:47 -0500 David Robillard <dave(a)drobilla.net> wrote: dbus ?

On Nov 11, 2009, at 7:42 AM, David Robillard <dave(a)drobilla.net> wrote: json is great. If you need binary rpc then take a look at bert. They could be good mediums for simple language-neutral data exchange.

On Fri, Nov 06, 2009 at 12:26:40PM +1100, Loki Davison wrote: Noted. I'm not going to spend time answering questions of who calls me a troll. Ciao, -- FA Io lo dico sempre: l'Italia è troppo stretta e lunga.

On Fri, 2009-11-06 at 15:00 +0100, rosea grammostola wrote: Seriously. The amount of completely baseless hand-wavey FUD nonsense that flies around this subject absolutely blows my mind... -dr

On Fri, Nov 6, 2009 at 6:08 AM, <fons(a)kokkinizita.net> wrote: fons, although i share some of your concerns about LV2's design philosophy, I don't think its fair to conflate this particular issue with extensions at all. there's no evidence here of any "conflict" between extensions. there was a revision to the core specification, and it was a fairly deep revision at that, albeit a small one. this made one (and at this point, it really does look like one) extension that was written using an older version of the spec now technically invalid (even though in practice it still works). this could theoretically happen any time that the core spec is modified, and it underlines how much more important it is for that to remain stable if useful functionality is developed in the more "ad hoc distributed" way that the extension mechanism provides for. but i really don't think it says *anything* about the extension mechanism at all. having seen the breadth of functionality offered by both VST and AU plugins, using APIs that in almost all respects provides no more functionality than LV2 core + some GUI extension, its hard for me to imagine what extensions you might want to be using in the context of a general purpose host like ardour. this is a clue: Harrison faced precisely this problem with mixbus (if you haven't noticed this yet, http://mixbus.harrisonconsoles.com/). They decided to take advantage of the fact that the host is open source and that it was less productive to try to define a *plugin* API that provided the required level of interaction with the core of the app. So they just hacked Ardour's code itself (even though the actual DSP involved is still in a LADSPA plugin). your preferred solution depends, fundamentally, on how much you *really* want some/all of those plugins to be re-usable. To take the Harrison case as an example, again: the plugin in that case is fundamentally *not* reusable outside of mixbus, even though its using an API that isn't ardour specific. if you *really* want your "type A" plugins to be reusable in other contexts, then *of course* you would develop them using a non-host specific API. LV2 might be highly appropriate for that, or not. But if you don't really care about that reuse, then of course your common, host specific API makes more sense and is less work. so, i don't really see this as having much to do with LV2, its current state or its design philosophy. i'd also note that while i too have been critical of LV2's design, i don't see anything else that can move us past the state of affairs that LADSPA represents. to the extent that the future of open source cross-host audio plugins, at least for linux, requires such an API, i think that LV2 is it. it does need some "social engineering" (i think that this is what jorn called it), but thats entirely different from postulating that the extension-based design is fundamentally flawed. --p

On Fri, 2009-11-06 at 12:08 +0100, fons(a)kokkinizita.net wrote: How could changing the rules about how anything references ports be done as an extension? The point of the change is that referring to indices makes things break. It has to be defined in the core to prevent this. It is associated with versioning. There are the sort of (very few) things that are, and must be, defined in the core. It is not so much a breakage specific to the GUI extension as an oversight that has now been resolved. ... What extensions are in conflict? FUD FUD FUD This doesn't really make any sense. This also makes no sense. It might be possible to deliberately construct a really, really, really cracked out extension that would somehow be in "conflict" with another, but I can't even come up with such a case. I'd say the chance of this happening with extensions that aren't deliberately written to do this is extremely close to 0. Even in this overwhelmingly unlikely case, if conflicting extensions existed it simply would not make sense to implement them both in a single plugin. Big deal. Maybe if you can come up with an example of such "conflicting" extensions... Fine then, don't. Nobody says you have to do anything. You not wanting to do stuff is certainly is not an argument against LV2. Lucky for you, because of the extension mechanism you ironically seem to hate, you can :) (see below) This is true, but the benefits are substantial, it's not "just" adding overhead. Extensions could be invented to avoid (most of) the text part entirely, but that's a lot of work for little gain. I'd rather just deal with that overhead as it comes up. What would these extensions be? And would they be mandatory for the plugins working whatsoever? All this is pretty much the cost of using a generic plugin mechanism. If you want them to work elsewhere, then yes, you should. Otherwise, they won't. If these needed extensions are absolutely necessary for the plugins to be in any way useful, and very non-generic and not likely to be implemented elsewhere, then the plugins are inherently not useful in general, LV2 or no LV2. This is pretty unlikely though. You can use C++ in an extension if you like. Such an extension would be trivial, e.g. "the extension_data method on a plugin, called with this URI, returns an object of this type". Might piss off some of the pure C people, but whatever. It's better to have LV2 plugins that (can) work in any C++ host than no plugins that work elsewhere at all. That said, it's certainly better to use C if possible... -dr

On Fri, 2009-11-06 at 18:27 +0100, fons(a)kokkinizita.net wrote: This would not solve the problem because hosts need to follow the rules too. The core spec obviously has to specify things like how to refer to ports correctly. There are a small number of things that need to be defined in the core spec for obvious reasons, this is one of them. This presumes that extensions "conflicting" makes sense, or is likely to happen. Why? Says who? Example? I don't know what this "order" stuff means at all. Extensions don't have an order. Extensions are usually either new port types, which can't conflict with anything, or newly added functions, which can't conflict with anything either. The only kind of extension that could "conflict" is what that redefines the semantics of something very fundamental in the core spec, which is silly, and again, even if such an extension existed, it doesn't matter, because that one particular weird extension might not make sense with such and such a host/plugins/extension/whatever. So? If it's fundamentally incapable of working in some setup, then it won't. You are making the outrageous claim, the burden of proof is on you. Again, what interactions and dependencies? You're waving your hands around screaming about "conflict" with no example or argument to suggest such conflict is likely or even possible. Is isn't, and furthermore, if it did happen it's not a big dealer, and furtherfurthermore, the community would take care of this anyway (why would anyone do this without a good reason? and if they did, why would anyone implement it?) Here is an actual example of the sort of way extensions might "conflict": Extension A says the block size passed to the process method must be always 1. Extension B says the block size passed to the process method must be always 512. These extensions "conflict". So what? You can't do both on the same plugin, obviously. The things they describe inherently "conflict". This is simply not a problem. If you think it is a problem, then come up with an example for why. I can't think of one. Maybe, and everyone would like as many plugins as possible, but you don't have any concrete reasons. I'd love to address your concerns, but you don't have any actual concerns. One can not make a patch for FUD. Why should you even care if this "conflicting" thing is possible anyway? Will it affect your plugins? Obviously not, you couldn't implement "conflicting" extensions on a single set of plugins anyway, by definition. A better analogy would be well-formed XML or RDF, where things can easily be added but it doesn't break anything because the technology has been designed specifically to handle this; or my shared library analogy from earlier. Having the data separate from the code is pretty much "required" to get all the things we want anyway. Is it more complex than is "required"? Maybe. It depends how you feel like conveniently defining "complex". Having an equivalently powerful data model defined in the code somehow is hardly free either. A vague notion of "complex" doesn't really matter much when there are tangible advantages/disadvantages to take into consideration. A lot of functionality can be implemented such that the plugin works without it. You don't /have/ to "require" them. This wouldn't be an LV2 plugin at all. -dr

On 11/08/2009 08:37 AM, Gabriel M. Beddingfield wrote: Would a set of reference template code written for the various languages that we have at our disposal be of any use here? I again ask for submissions. Even if we just have one template that we can agree on it won't be that much effort to port it across to the other languages that we would like to have supporting LV2. that will make things that much clearer for developers across the board. The standard in the closed source world is to provide a package with the example code in place add some descriptive comments and a web accessible howto and we are good to go. It's clear that we need to better define the plugin publishing and dependency system for LV2? We need a more transparent way of referencing an extension/plugin by to it's dependencies.

On 11/08/2009 03:31 PM, Gabriel M. Beddingfield wrote: Is it just me that feels that the existing examples are too obscure and set the entry level too high for the average developer as well as miss out important use cases specific to different languages? On another tangent is LV2 supposed to be a new standard and therefore provide an accessible documentation codebase for all potential users or is LV2 designed as a theoretical system which only advanced developers are given insight into and the rest have to fend for themselves. What you have written below could also be considered a definition of a set of rules for publishing and specifying dependencies. However it doesn't completely address the dependency issue. Even if this standard was followed how would we define the categories such as "LV2 Synth Plugin"? Is that something that would be handled as someone else has suggested on a yearly basis by a committee?

On Sun, 2009-11-08 at 11:30 -0600, Gabriel M. Beddingfield wrote: Plugins should use whatever extensions they please. Plugins should under no circumstances /require/ extensions unless it is absolutely necessary to do so for the plugin to work at all. Given this, there is little need to "limit" yourself. Necessity is necessity, regardless of what the house judiciary committee on LV2 extension support decides people "should" implement ;) Easy documentation about which hosts support what is indeed useful, but you can't come up with a "consensus" about what hosts "should" support. They "should" support everything ;) It's what they DO support that matters. There's been far, far, far too much yapping about this on the list at this point. Yes, we need a compatibility matrix or something along those lines. Everyone agrees. There is really no need to continually state it. SOMEONE MAKE ONE ON THE DAMNED WIKI THEN The problem is simply a lack of documentation. The solution is to write it. There is certainly no utility in complaining about these problems at this point. "Those who can do, those who can't complain". Since there seem to be several people who are really, really into this problem.... solve it already. Using mediawiki is not difficult. -dr

On Sun, 2009-11-08 at 21:24 +0200, Nedko Arnaudov wrote: Well, there are certainly a lot of people complaining about it, so that suggests the plugin authors /aren't/ doing it. Somebody has to. The wiki provides a way for those prone to whining to actually do something about it. A central overview of the state of compatibility would be useful anyway, and seems to be largely what people are asking for. If the information was spread all over the place there would be much less utility for people looking for which extensions it is wisest to use (e.g. Gabriel). IMO 99.99% of these complaints are really just about people going to lv2plug.in looking for information and finding a big random pile of inconsistent crap. People seem to like to extrapolate this to some kind of argument about the technology, but they are wrong. There needs to be a good, coherent, and consistent source of documentation for things LV2, to address these concerns. I am dealing with this problem as far as extensions goes, but not the "what supports what" stuff. New idea: it is tempting to define a very simple turtle document format for hosts to signify what they support, then this kind of compatibility information could be automatically generated as well (and in a much more useful form than a human could put together). The information is already there for plugins. As far as I'm concerned the lack of automatically generated documentation (and/or machine readable data in general) is pretty much the sole reason for every single complaint related to this whole thing. This way is also decentralized, but the results for all "known" implementations could be hosted at lv2plug.in (or anywhere else) for convenience. I am surprised I didn't think of this before, but it seems to be a pretty good idea. All that is needed as far as maintenance goes is for hosts to supply a simple turtle document that says "I implement foo and bar and baz extensions". The rest can be compiled into whatever fancy human readable form you want, for every single plugin out there, by a tool. If I provide a template, would anyone be willing to put together these documents? I will gladly write the tool if the data is there, and the problem will be solved, and a convention set that solves it in the future with basically no effort involved. 3. How "well supported" is this extension, and should I use it in my new plugin? This question needs an overview. Even if plugin and host authors supply this information, an overview is useful. -dr

On Sun, 2009-11-08 at 21:46 +0200, Nedko Arnaudov wrote: Mosts hosts don't even have RDF metadata. DOAP is just one vocabulary, I agree it should be shipped with hosts though, and all data should probably be in the same document (doap stuff, supported extensions, whatever else). This would be a good precedent to set. This is another reason for automatically generating it. Considering all the versions, and all the permutations of hosts/plugins, doing it as a human maintained static set of documents isn't really feasible. The point is that having this stuff scattered all over the place doesn't really solve the problem. We need to establish a standard format for this data, gather the data (in a distro-agnostic format (RDF)), write the tools, and get it done. People can package the results and integrate it with whatever other things as they please. Integration with packaging systems might be nice (for people that use those distros) but doesn't solve the problem. First thing's first and all that. -dr

On Sun, 2009-11-08 at 21:13 +0100, Thorsten Wilms wrote: Ideally, yes, but it would be more productive to just put together this data now and deal with that later. Like everything else, it should probably be just bundles distributed, installed, and discovered, in the usual way. I will write a vocabulary and simple template later today. -dr

On Sun, 8 Nov 2009, Gabriel M. Beddingfield wrote: Erm... nevermind. You've already finished it. :-) -gabriel

On 11/09/2009 06:39 AM, David Robillard wrote: I will work on the docs. Patrick Shirkey Boost Hardware Ltd

On Sun, 2009-11-08 at 20:23 +0000, Chris Cannam wrote: This is a problem that hosts (can, and) should express to the user in clear terms. They shouldn't have to go digging around on the internet to figure this out (this is a large part of the reason I maintain these "problems" are severely exaggerated around here). The number one rule of offline documentation is that nobody reads offline documentation :) -dr

On Sun, Nov 8, 2009 at 3:36 PM, Chris Cannam <cannam(a)all-day-breakfast.com> wrote: [X] This plugin was discovered but can't be used without hacking this host and recompiling because its uses an extension that isn't currently supported. That kind of PITA? :)

On Sun, Nov 8, 2009 at 8:53 PM, Chris Cannam <cannam(a)all-day-breakfast.com> wrote: Also -- are you, like me, bored with LADSPA plugins crashing your host in tedious, obvious ways? How about an LV2 plugin that expects a particular extension but doesn't really need it so marks it as optional, then turns out not to have been tested without it -- and, wouldn't you know, every host except yours happens to support that extension? Wouldn't you love to be the first host to run the untested code path in production? (I freely admit that this is a sort of FUD, but it happens to be a FUD that is playing on my own mind at the moment. Reassure me.) Chris

On Sun, 8 Nov 2009 20:53:40 +0000 Chris Cannam <cannam(a)all-day-breakfast.com> wrote: Example: Synth plugins in Ardour 2.x, loadable but unusable

On Sun, Nov 8, 2009 at 9:24 PM, David Robillard <dave(a)drobilla.net> wrote: Sorry, I meant that as shorthand for first run of the host after new plugin was installed. Chris

On Sun, 2009-11-08 at 20:36 +0000, Chris Cannam wrote: Yeah, not displaying plugins at all is less than good. It really depends on context, but something alone the lines of showing all the plugins, but with unsupported ones grayed out with a little info icon you can click for the reasoning why, would be best. A user option could turn this off to make unsuitable plugins not be in the way and shrink the list. In menus it's a bit more complicated. I suppose clicking on an unsupported plugin (that should be visually flagged in some way) can bring up the 'why' info. -dr

Here is what should be (IMO) with current extension list (as i know it): "Gabriel M. Beddingfield" &lt;gabriel(a)teuton.org&gt; writes: * the MIDI event extension * the Event port extension * the URI map extension * the external UI extension GTK hosts must support the GTK UI extension currently, parameter ports and monitor control (float) ports are supposed to be used for this. event ports could be used for parameter and monitor events but i'm not aware of someone using them for this purpose. I don't get why such restriction is needed. Plugin author can assume that these are available: * the MIDI event extension * the Event port extension * the URI map extension Plugin author can assume that one of these are available: * the external UI extension (toolkit agnostic, always a window) * the GTK UI extension (gtk specific, may be embeded) See comments for matching guidines for hosts above. UI extensions are of course optional but hosts will handle this gracefully anyway, as defined by LV2 itself. I.e. if plugin provides no GUI, then host will probably use generic one (prefered) or will not allow parameter tweak. If host does not support these GUI extensions, it will not show the GUIs. That said, most users expect plugins to have GUIs, and GUIs running on same host as the DSP code. Some words about the GUI extension problems. If we want (we do, right?) wider adoption of LV2, GUIs must be toolkit agnostic and at least C++ SDK must be provided. External UI may not be perfect but IMO (obviously) it is the best we have in this direction. The GTK extension could be supported automagically if plugin author inherits its GUI class from the GTK plugin GUI base class. proposed class hierarchy: lv2_plugin_base / \ / \ / \ / \ lv2_synth_plugin lv2_effect_plugin | | mysynth myeffect lv2_plugin_base implements the base lv2 plugin functionality lv2_synth_plugin implements the lv2 synth functionality lv2_effect_plugin implements the lv2 effect functionality lv2_ui_base / \ / \ / \ lv2_gtk_ui_base lv2_external_ui_base \ / | \ \ / | \ \ / | \ \ / | \ \ / | \ lv2_gtk2_gui lv2_qt4_gui lv2_fltk2_gui | | | mygtkui myqtui mygltkui lv2_ui_base implements the base UI extension lv2_gtk_ui_base implements the GTK variant of the UI extension lv2_external_ui_base implements the external variant of the UI extension lv2_gtk2_gui implements the base functionality of a GTK GUI lv2_qt4_gui implements the base functionality of a QT4 GUI lv2_fltk2_gui implements the base functionality of a FLTK2 GUI Current problems with the UI extension (both gtk and external variants): * there is no easy way for UI to know the sample rate * it is incompatible with lv2core revision 3 If new UI extension is designed, it should probably use event ports. When the original UI extension was designed, event port extension was not avialable. Of course, others are free to disagree. -- Nedko Arnaudov <GnuPG KeyID: DE1716B0>

On Sun, Nov 8, 2009 at 7:35 AM, Gabriel M. Beddingfield &lt;gabriel(a)teuton.org&gt; wrote: when you come up with a way to do that, please do let us know. this has been on the table for at least 8 years and no acceptable solutions have ever emerged. they either offer too little control to the plugin developer, or simply cannot integrate with the event loop of the host.

On Sun, 8 Nov 2009, Paul Davis wrote: OK, I've dutifully searched the LAD and LV2 archives..... :-) Why did XEmbed not pan out? I didn't see anything negative regarding its adoption... people just quit talking about. It doesn't even look like it was discussed on LV2-dev. -gabriel

On Sun, 2009-11-08 at 08:30 -0600, Gabriel M. Beddingfield wrote: I don't think anyone who cares about Qt has done much in LV2 land yet :) -dr

On Sun, Nov 8, 2009 at 4:09 PM, David Robillard &lt;dave(a)drobilla.net&gt; wrote: Not just "can", it does by default since Qt 4.4. I think the intention was exactly to allow cross-toolkit plugins. So it's quite likely there is a way to make this work, though obviously not with the existing GTK UI extension. Wish I had time to look into this myself, but I haven't. Chris

On Sun, Nov 8, 2009 at 6:59 PM, David Robillard &lt;dave(a)drobilla.net&gt; wrote: Because it passes a GTK window, doesn't it? (Doesn't it?) Which has no meaning anywhere except GTK. Chris

On Sun, Nov 8, 2009 at 7:18 PM, Nedko Arnaudov &lt;nedko(a)arnaudov.name&gt; wrote: Right, OK, same thing though from this point of view. GTK anything. Chris

On Sun, Nov 8, 2009 at 7:25 PM, David Robillard &lt;dave(a)drobilla.net&gt; wrote: Uh, with an X window or whatever. GTK and Qt are both X toolkits after all. In any case, it doesn't have to be embeddable to be useful -- it only has to be in-process (even if in a separate window) to be better than the DSSI alternative. But it's only of any use at all if the host and plugin know what the void pointer points to. Presumably the extension provides a way to communicate that; otherwise, it either really is a GTK UI extension (because there are GTK plugins that use it already, so all hosts must assume the unknown void pointer is a GTK widget pointer), or else it's just a very fancy segmentation fault extension. Anyway, even if you can write plugins using any toolkit and run them in a host that uses any toolkit, I posit that a UI extension in which the UIs only appear if the plugin and host happen to be using the same toolkit is not a very useful one. Chris

On Sun, 2009-11-08 at 19:43 +0000, Chris Cannam wrote: Then it's X specific. I'd rather implement the embeddey part in a library that can take a void* pointer to a somethingorother (where the type is specified) and deal with the details. Having a bunch of X specific junk in hosts isn't that much more palatable than a bunch of Gtk/Qt/whatever specific junk anyway. Obviously there is ;) It is an extension by which you can easily find a UI of some type for a plugin. No more, no less. What is possible with those types, or what types are used in practice, is (deliberately) an orthogonal problem. -dr

On Sun, 8 Nov 2009, David Robillard wrote: I agree. Can you suggest another metric? -gabriel

On Sun, 2009-11-08 at 14:00 +0200, Nedko Arnaudov wrote: To clarify, since this could be misleading: the UI extension is not a Gtk UI extension, it can work with any toolkit or other form of UI, including 'external' ones. These can both be fixed without breaking backwards compatibility by passing features to the UI. I said the last time something came up with the UI init function that things should just be passed as features instead of breaking the thing every time we feel like adding a parameter for "convenience". That time has certainly come now. It should be completely port type agnostic, as it is now. -dr

On Sun, 2009-11-08 at 12:44 -0600, Gabriel M. Beddingfield wrote: This extension is IMO a kludge (because it's not extensible and is too kitchen sinkey), which is why I havn't implemented it (and won't). It doesn't mesh well with anything else. A more generic dynamic ports extension (that allows dynamic adding/removing of ports without all the other crap) would certainly be nice though. -dr

On Sun, 2009-11-08 at 21:17 +0200, Nedko Arnaudov wrote: If you mean visually, I think a straightforward "view priority" or something along those lines property is the solution to this (this problem is common to basically anything that shows all controls, not just ingen). Priority 0 would be a small number of high level controls that should be visible whenever any control are (e.g. overall gain), Priority 1 would be slightly more low level controls (e.g. filter cutoff), and so on. Priorities could be associated with groups as well as ports to make things more managaeable. Easy enough, just needs doing. -dr

On Sun, 8 Nov 2009, David Robillard wrote: Several as in "a non-negative integer." I.e. the host should be prepared for a synth that has 1, 2, 3, 4, or even 0 ports. :-( Good to know, though. But if you know up-front which things to make optional... you can adjust your implementation. So that I can write a synth plugin and be reasonably assured it will work with "everyone's" LV2 synth host. So that I can write an LV2 host and be reasonable assured that it work with "everyone's" LV2 synth plugin. Because Synths are usually more complicated than an effect, and less well-defined conceptually. There's presets, samples, MIDI implementations, sound libraries, routings, effects in the sampler, variable number of ports, various ways to pass data, etc. ...but much harder to *discuss*. ;) -gabriel

On Sun, 2009-11-08 at 19:43 -0600, Gabriel M. Beddingfield wrote: Hrm, WTF! Good question. Steve? -dr

On Sat, 2009-11-07 at 15:37 -0600, Gabriel M. Beddingfield wrote: Actually I specifically said making a list of "well supported" extensions was a good idea. Making a bunch of different "categories" of LV2 support is stupid, and claiming the extension thing is some apocalyptic disaster with no evidence is FUD. Dave is, at this moment, working on "The Problem" (documentation). Actions speak louder than words. -dr

On Sat, 2009-11-07 at 23:09 +0100, fons(a)kokkinizita.net wrote: Huh? An LV2 plugin in the code sense is a shared library with a lv2_descriptor function that returns a struct LV2_Descriptor (just like LADSPA). I don't see how a shared library with some random C++ object in it is an LV2 plugin... or what the point would be anyway -dr

On Sun, 2009-11-08 at 19:13 +0100, fons(a)kokkinizita.net wrote: I assumed this object would be an auxiliary thing, because that's all that makes sense. Making an LV2 plugin that doesn't actually use the LV2 methods doesn't make any sense. It could technically have those fields but have them not do anything and theoretically be a "valid" LV2 plugin I suppose, but it's a completely braindead and pointless thing to do anyway, so who cares... If the motivation for this is the fact that this class already exists, then simply make the LV2 methods call the methods on that object. The "bypass LV2 entirely" thing you describe is crazy. No point in using LV2 at all, that way. At best it's just being a huge pain in the host author's ass for no reason. -dr

On 5 Nov 2009, at 23:33, David Robillard wrote: This was a hangover from LADSPA, which had confusing and contradictory claims about what should/shouldn't be used to identify ports. I still don't think there's consensus there. - Steve

On Sat, 2009-11-07 at 13:41 +0100, Jörn Nettingsmeier wrote: Labels are not useful as an identifier for LADSPA ports at all - there are plugins out there that use the same label for several ports, for example. Despite this there's code out there that attempts to use them as such. More generally there's been a lot of confusion and screw-up over identification of plugins. The spec says to use the ID, which is annoyingly centralized and limited. There are plugins in the wild with conflicting IDs. Many people suggested using the library name and plugin label as an identifier instead. Unfortunately this doesn't work, there are packages of the same plugins with different library names, or different distributions of plugins among libraries. I don't believe there is a single correct way to refer to a LADSPA plugin that actually works with all the plugins out there. Many people just have an extremely small number of plugins (e.g. 2 or 3 of the most popular big packages) and don't notice. The index vs. symbol thing with LV2 is more to do with dynamicism and versioning, though. -dr

On 7 Nov 2009, at 20:15, Chris Cannam wrote: Oh you're right, brain fart on my part. Still the port ID in LV2 was a hangover from LADSPA, which was my main point. - Steve