[Clam-devel] ladspa progress

[Pau Arumi]

thanks a lot for the patch andreas. we are almost there with ladspa support!

i've just commited all the changes in the patches. i've been moving 
Ladspa classes from NE/ to CLAM/ and changed Network so it makes use of 
LadspaFactory when the "normal" factory throws exception.
LadspaFactory is still not functional, as we talked over irc.

some TODOs i've been noticing while revising your patches

- LadspaFactory cxx and clean commented code
- Network: catch FactoryError
- HIGH: update LadspaFactoryTest with "real" classes
- fix non-string bug in LFactory map
- ProcessingTree.cxx line 200 remove USE_LADSPA conditinal code. always use
  className = item->text(1)

that's all for now. waiting for your next patches. keep it up ;-)

pau


En/na Andreas Calvo ha escrit:
> The last few days I've running some tests under the ladspa support for 
> CLAM, based on a UnitTest (LadspaFactoryTest) that Pau gave me.
> That leaded to some big changes in the structure.
> The main problem was that the current factory was not compatible with 
> what we need to wrap a ladspa plugin, so first step was to make a 
> LadspaFactory (and later we'll merge it with the current factory 
> somehow).
> On the other hand, as opposed as the current processing, Ladspa needed 
> a little bit more information. So there's a new class called 
> LadspaPluginExplorer which generates a structure that holds all the 
> information needed and give it to the ProcessingTree to generate the 
> LadspaTree (in fact, it's a use-and-trash object).
> Next we created two new classes, LadspaWrapper and 
> LadspaWrapperCreator... Sure the name explains by itself, but first 
> one it's a wrap of a ladspa plugin, and the second one it's called in 
> the LadspaFactory to store objects with their key.
> I'll add the patches, but I think they may be very unstable.
> First add the ladspa patch, and then add the processing_tree patch.
>
> Regards,
> Andreas