Hi LAD! We are working on a project (more news soon) and as part of our job we are porting some good old LADSPA and other plugins/effects to LV2. So far we have CAPS, TAP, some Guitarix and Rakarrack stuff. Also we've been working on some LV2 plugins (sooperlooper-lv2 for example, you can find what I'm doing here: http://github.com/brunogola/sooperlooper-lv2-plugin ) As we are in development/testing phase we never released anything, but I think it's time to release our work on CAPS so you don't have to do the same we did already. So... http://github.com/portalmod/caps-lv2/ You may notice some new extensions inside the .ttl files, we are working on some documentation for that. On Thu, Nov 29, 2012 at 3:12 PM, brummer- <brummer-(a)web.de> wrote: -- Bruno Gola <brunogola(a)gmail.com> http://bgo.la/ | +55 11 9-5552-3599

On Thu, Nov 29, 2012 at 5:33 PM, Aurélien Leblond <blablack(a)gmail.com> wrote: sure, working on that. -- Bruno Gola <brunogola(a)gmail.com> http://bgo.la/ | +55 11 9-5552-3599

Am 03.12.2012 16:43, schrieb Bruno Gola: Hi I really interested to see what you have done, and which modules you build from guitarix. Hopefully we can merge some of your work back to upstream. I'm myself work at time on a amp (12ax7)-> tonestack ( sovtek)-> cabinet (4x12) module as a basic amp. I use our libgxwmm for the GUI building and come close to the orginal guitarix interface. regards hermann

On 11/29/2012 06:36 PM, Bruno Gola wrote: Cool, thanks for this! I'm ready to upload a source package to the KXStudio-Team plugins repository but I get some messages that are not supposed to be there I think: lilv_plugin_load_ports_if_necessary(): error: Plugin <http://portalmod.com/plugins/caps/Eq> port symbol `2khz' is invalid lilv_plugin_load_ports_if_necessary(): error: Plugin <http://portalmod.com/plugins/caps/Eq2x2> port symbol `31hz' is invalid lilv_plugin_load_ports_if_necessary(): error: Plugin <http://portalmod.com/plugins/caps/VCOd> port symbol `1trisaw' is invalid This is with Qtractor 0.5.6. Also, what is the version number of this release? Or do you use the CAPS release version (0.4.5)? Regards, Jeremy

On 11/30/2012 01:44 AM, Ricardo Crudo wrote: Hi Ricardo, Thanks, just git pull'ed in the changes. But what is the version number? or is caps-lv2 not ready for realease yet? Regards, Jeremy

[Bruno Gola] After having had a quick glance, it seems the structural changes made to the source tree will make reflecting upstream development a bit difficult, or is my perception failing? Cheers, Tim

[Bruno Gola] I'll be happy to answer any questions about CAPS internals you may have (though it would seem you have a good enough grasp already). At any rate, limiting your changes/additions to to the common interface files (basics.h and interface.cc), if possible, will certainly make following upstream a lot easier. Although this seems viable to me, I should add that I have no actual knowledge of LV2 except the little gathered from glancing over your code, and this is unlikely to change soon. This lack of expertise also implies that it would be unreasonable for me to merge and maintain an LV2 interface. Cheers, Tim PS: For some reason I couldn't seem to locate basics.h in the above github tree.

On Thu, 2012-11-29 at 23:15 +0100, Tim Goetze wrote: It's not so much about efficiency, but that wrapped plugins tend to be flakier, and a bit less pleasant to work with in some cases. Since the common part of LADSPA and LV2 are so similar, I doubt it would be that much work. Instantiate has a different signature and things take void* instead of float* pointers, but that's about it for plain LADSPAey plugins. Of course since someone has apparently already done it, we should probably just look at that, but whatever :) Hopefully it was done in a way mergeable with upstream. Most "conservative" hosts already do, however there are no plans to make Ingen (the host Aurélien is interested in) or Jalv support LADSPA. These are "next-generation" LV2 only tech, supporting LADSPA would bog down their development, bloat the code, and cause a bunch of unnecessary ugly/hard problems I have neither the time nor desire to solve. I dropped it some time ago on purpose. There are other LV2 only hosts as well, and that number will likely increase over time. That said, you can use NASPRO to use all LADSPA plugins in any LV2 host, with a few minor degradations from real LV2s (e.g. no nice port symbols). This means you have to have NASPRO and load/execute dynamic library code at discovery time, of course (which with LV2 is not the case), via the dynmanifest extension, but any host that uses Lilv automatically supports this, assuming support is compiled in. It is because this exists that I dropped the redundant and half-baked LADSPA support in Ingen itself (plus it works for other APIs, like VST, too). Any problems with bridging should be addressed in NASPRO, though as far as I know it works well. Native ports are, of course, the nicest. If the plugin code is already abstracted away from the API, that's the way to go. Cheers, -dr P.S. This is not intended as a suggestion for anyone else. By all means, implement LADSPA in hosts, it is a reasonable thing to do. I simply do not have the time to do so, Ingen is quite a fancy thing architecturally and there is still much work to do to fully realize it without adding that to the pot, and much of it is blazing new territory which needs the additional functionality and extensibility of LV2 to happen anyway. If you want compatibility with old things, it is not the host for you. Naturally, I consider incentive to port to LV2 a feature and not a bug anyway :)