[Clam-devel] ladspa progress

Pau Arumi parumi at iua.upf.edu
Mon Mar 19 05:48:46 PDT 2007

a couple of follow-up comits:
 * (hopefully) fixed compilation when USE_LADSPA is undefined. (red in 
 * fixed LadspaNetwork::RegisteredKeys() (forgot to return the result! )

now the LadspaFactory keys seems ok. but NE crashes when dropping a 
ladspa object.
the problem is in NaiveFlowControl.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1249360176 (LWP 9124)]
0xb7f42a7a in CLAM::NaiveFlowControl::ProcessingAddedToNetwork ()
   from /home/parumi/local/lib/libclam_core.so.0
(gdb) bt
#0  0xb7f42a7a in CLAM::NaiveFlowControl::ProcessingAddedToNetwork ()
   from /home/parumi/local/lib/libclam_core.so.0
#1  0xb7f46077 in CLAM::Network::AddProcessing ()
   from /home/parumi/local/lib/libclam_core.so.0
#2  0xb7f463da in CLAM::Network::AddProcessing ()
   from /home/parumi/local/lib/libclam_core.so.0
#3  0xb7f46abd in CLAM::Network::AddProcessing ()
   from /home/parumi/local/lib/libclam_core.so.0
#4  0x081286f2 in NetworkCanvas::addProcessing (this=0x825dd70, point=
      {xp = 217, yp = 210}, type=@0xbffc4d14)
    at src/generated/../NetworkCanvas.hxx:396

En/na Pau Arumi ha escrit:
> 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
> _______________________________________________
> Clam-devel mailing list
> Clam-devel at llistes.projectes.lafarga.org
> https://llistes.projectes.lafarga.org/cgi-bin/mailman/listinfo/clam-devel

More information about the clam-devel mailing list