[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
windows)
* 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