[Clam-devel] today's commits: ladspa functional (not perfect) and 0.99 release

Tue Mar 20 01:34:32 PDT 2007

Some last hour bug fixing commits related to Ladspa, before 1.0:

I fixed the doubled ports bug on the ladspa adapter implementation. The reason 
was not clearing the existing ports on configuring. When loading the 
Configure was called twice, on the constructor and then on the explicit 
configure.

This was the bug i mentioned Pau yesterday to solve, but while solving that i 
detected some other bugs. 

The first one is about deleting ladpsa plugins. Processing destructor didn't 
delete the ports so connected inports of other processing cannot be connected 
again. Easy to fix, the deleting function was even implemented but not called 
by the constructor.

Other bug was about multiport plugins. All the Ladspa ports were feed with the 
same CLAM port (index 0 is always used). A couple of variables were used but 
not incremented. Easy fix too.

And another bug on the controls. When we send control information the 
NetEditor crashed. We linked the controls to an array of floats where we put 
the data. This link was done while adding the control ports and the float 
array grows with push_back. But this means that the array is reallocated so 
previous pointers are no more valid. I did that in a separate bucle after all 
arrays are created.

Commits 9876 and 9877.

Ladspa integration seems promising and very funny and it's going to make 1.0 a 
big step forward even we didn't pretend so. So keep with the nice work, 
Andreas.

David.

On Dilluns 19 Març 2007, Pau Arumi wrote:
> summary:
> a very busy development day! ladspa is working. see:
> http://iua-share.upf.edu/wikis/clam/index.php/Development_screenshots
> today's "silent" 0.99 release went well, tomorrow we'll do the
> 1.0 release.
>
>
> commits:
>
>   * small changes in doDebianPackages and ProcessingTree (removed
> couts)
>
>   * LadspaFactory now uses ErrFactory. this fixes a bug whith non
> existing key in NE
>
>   * extracted ErrFactory.hxx from Factory.hxx
>
>   * Networks/ProcessingDefinitionAdapter now uses LadspaFactory
> as a fall-back to create processings like Network does
>
>   * LadspaWrapper and LadspaWrapperCreator added a new attribute
> _factoryKey and defined GetClassName to it. this fixes save and r
> estore xml netwrok  with ladspas
>
>   * NetworkEditor/README added Prototyper usage
>
>   * ProcessingTree.cxx added "experimental" comment on LADSPA
>
>   * follow-up of last commit: removed AudioOut closes bug #198
>
>   * removed AudioOut from NE ProcessingTree (now we use PortAudio)
>
>   * removed "won't work" comment in LADSPA sub-tree
> (ProcessingTree.cxx)
>
>   * fixed bug (from last ladspa commit) in Network: created
> wrapper was discarded
>
>   * LadspaFactory: simplified error code
>
>   * LadspaPluginsExplorer removed couts
>
>   * LadspaWrapper: removed couts
>
>   * fix for last ladspa commit: ProcessingTree.cxx needed an include
>
>   * Network.cxx: adding debug traces to locate LadspaWrapper bug
>
>   * fix last ladspa commit: ProcessingTree.hxx should not include
> LadspaFactory
>
>   * hopefully fix for compilation of non-defined USE_LADSPA
>
>   * fix last commit: Network.cxx should have #ifdef USE_LADSPA
> protections around LadspaFactory
>
>   * fix last commit: LadspaFactory::RegisteredKeys() didn't
> return. it was an ugly bug
>
> * more comments for the last ladspa related commits:
>   * finished (quick and dirty) LadspaFactoryTest
>   * created NetworkEditor/src/LadspaFactory.hxx
>   * added ladspaFactory to ProcessingTree
>    * created factory
>    * add creators for all plugin
>    * set factoryID in drag object
>     + made LadspaFactory a singleton
>     + moved DummyLadspa to LadspaWrapper
>     + created LadspaWrapperCreator
>     + use CLAM::Processing
>     + use hidden column 1 in ProcessingTree to store the
> className (or factorID)
>
>   * applyied several andreas calvo patches towards integrating
> LADSPA
>   with the Factory infrastructure. thanks a lot andreas!!
>   andreas' description of the changes:
>     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.
>
>   * Changes in Network so it uses LadspaFactory when the normal
> factory
>   rises an exception. Still not functional.
>
> _______________________________________________
> Clam-devel mailing list
> Clam-devel at llistes.projectes.lafarga.org
> https://llistes.projectes.lafarga.org/cgi-bin/mailman/listinfo/clam-devel

-- 
David García Garzón
(Work) dgarcia at iua dot upf anotherdot es
(Home) vokimon at telefonica adot net
http://www.iua.upf.edu/~dgarcia
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.clam-project.org/pipermail/clam-devel-clam-project.org/attachments/20070320/71888c0e/attachment-0003.pgp>