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

[Pau Arumi]

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.