Re: [LAD] CAPS* as LV2

On Thu, 2012-11-29 at 23:15 +0100, Tim Goetze wrote:
> [Aurélien Leblond]
> >Quick question: does the CAPS* plugins suite exist in LV2 format (I'm
> >almost sure the answer is no, as I have looked everywhere, but you never
> >know...).
> >
> >If not, could somebody who knows the code of these plugins let me know how
> >hard it would be to port them to LV2? Are there any pitfalls to look for?
>
> The C* plugins are still being actively developed, the rarity of
> public releases notwithstanding. Of course, if you're happy with a
> port being a static snapshot, this may not bother you. In any event,
> an automated wrapper is probably the best option.
>
> (There is a central abstraction layer internal to CAPS that does allow
> you to implement alternative plugin APIs without having to touch
> existing code while likely being compatible with future releases. If
> you want to go down this road you'll need to live with three things:
> the plugin abstraction makes use of C++ templates, it's constructed
> around port struct definitions from ladspa.h, and port default values
> are only described roughly, using the idiotic mechanism that LADSPA
> provides. Ultimately however this approach would be a lot more work
> than the wrapper, for likely negligible efficiency gains.)

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.

> In the end, if you're looking for a constructive solution, I think
> that extending the host application of your choice to support LADSPA
> might prove to be the most fruitful direction.

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 :)

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev