Talk:LV2 Support

Section 12 of Project Plan (optional)
James 09:58, 13 June 2008 (PDT): For me this optional part:


 *  12. Investigate the possibility of rewriting the Vamp plugin architecture as an LV2 extension, to reduce the number of separate plugin architectures in use. This part would not result in any complete code but rather in a report on a webpage containing possible directions for further development and maybe a simple proof-of-concept skeleton of an LV2 extension specification or some pseudo-code.

has a long term strategic value. If it is possible that Vamp and LV2 can evolve to be one and the same standard, that means a considerable saving in development work. Particularly a saving in Chris' time if he is able to add 'Vamp' features to Audacity that simultaneously benefit LV2, and to take advantage of existing LV2 features when adding 'Vamp' analysis plug-ins. Your GSoC project was accepted on the basis of 1-8 being core, and everything else optional. That's fine, and I'm not asking you to change that. However, I personally see 6,7,8 as being lower yield for the work done than 12 would be - if a merger is possible. Also 12 is something that benefits from time during GSoC from other people to digest it. So if it is possible to slot in an aspirational goal to produce something for 12 shortly after the mid term evaluation - assuming the project is still going as well at that point as it is now - that would be great.


 * Larsl That would be OK for me, and it could probably done in parallel with some of the coding. Chris, any opinion?

Chris I would certainly like to see a proper report on this -- but I don't think it should take priority over anything I actually need to be able to "mark" for the purposes of GSoC!


 * James Chris: In giving pass/fail at mid term and end, it's the core items that matter. However your evaluation at the end of the project should report on optional items too.  What optional items (if any) get done is up to you and Lars to agree.  No question about it, if Lars does work on 12 it "get's credit" in the end evaluation (same is true for 6, 7 or 8).

Chris My feeling is that this may turn out to be a square peg in round hole scenario, because of the functional differences between Vamp and LV2 plugins that are not always expressed in the formal API -- for example the fact that Vamp plugin parameters can't be changed after the plugin is initialised, the very precise definition of construction/configuration/initialisation/process ordering necessary for Vamp plugins (see e.g. What can depend on a parameter? on page 11 of the Vamp plugin programmers' guide), the getRemainingFeatures function, input domains and output structures, and so on. These differences after all explain the existence of Vamp in the first place.

I only wrote the Vamp programmers' guide quite recently, and it's been quite an education in terms of revealing the non-API functional requirements for the host in particular. Consequently I think the problem of harmonising Vamp and LV2 is harder than I originally thought it might be. However, it's entirely likely that a fresh look at the situation from someone familiar with LV2 would make the problem look easier again; I don't know.

The Vamp SDK is more lightweight than the existing libraries used for LV2 (because Vamp doesn't require RDF), so turning Vamp into an LV2 extension or set of extensions would need some positive justification, in terms of what it made possible, because it would have the effect of making Vamp harder to support (in build/deployment terms) for any host that did not have other reasons to use RDF or support LV2 effects plugins.

Note also that there is separately some work afoot at QMUL to provide RDF metadata to accompany Vamp plugins and describe their output (see e.g. this provisional Vamp plugin description ontology and the work of Yves Raimond in audio feature description). Although my name appears as one of the foaf:makers in vamp.n3, I haven't actually had anything to do with defining this work myself, though I may make use of it in future versions of Sonic Visualiser et al. I don't see this as actually part of the API, in contrast to LV2 (it's a more "old fashioned" API than that!).

Expat
James 02:18, 26 June 2008 (PDT) A question about Expat. There's a copy of Expat inside wxWidgets. Are you using that or another copy? If you're using the version in wxWidgets, could that cause problems when we update wxWidgets (only) or update LRDF (only)? If you're using your own copy, could you say a few words about it, e.g. version number, why linking against that (and not wxWidgets version) happens etc. Also some kind of brief summary of other libraries brought in for LV2, and their dependencies in the configuration you've chosen would help make things clearer for me.