[Clam-devel] [PATCH] pulling up the Processing Factory the to base Factory class
Pau Arumi
parumi at iua.upf.edu
Thu Aug 9 09:28:02 PDT 2007
The patch have been improved (in a pair programming session with
Andreas) and commited on revision 10592
Commit log:
* All ProcessingFactory metadata has been pushed to Factory base
class so now we can use the registrator
to put metadata
* New registrator tests
* Removed LadspaPluginsExplorer class
* Ladspa loading is done in RunTimeProcessingLibraryLoader
** TODO: refactor: extract two different subclasses in different
cxx one for clam plugins other for ladspas
* MyFFT: small fix on registrator
* ProcessingTree removed commented out code
Now, next todos on the plugins area are:
* Change static metadata classes to Registrator char*
constructor for the spacialization plugin
* The same for (some) clam processings (not plugins)
* NE/ProcessingTree use some category attribute to construct
the tree
* 'Milestone: get rid of the char* processingClasses[]
hardcoded tree.
* use some attribute to distinguish LADSPA and CLAM (and...) =>
so processing tree does not know about ladspa
* Factory refactoring: unify two registry maps (creator and
metadata)
* Refactor RuntimeLibraryLoader to separate Ladspa and clam
plugins. Use hollywood (template method) pattern.
* Add plugin functionality (ladspa, clam) to OfflinePlayer. Or
any NetworkPlayer class actually.
o compile agains RunTime(Ladsap)Loader.cxx
Not so high prio:
* load lv2 plugins
* load lv2 midi plugins
pau
En/na Andreas Calvo ha escrit:
> This patch makes a movement from the Processing Factory to the base
> class of the Factory.
> Since all plugins stored in the factory will be tagged in some way, it
> was needed to pull up all definitions and methods of the Processing
> Factory class.
> BTW, the Processing Factory singleton has been kept until a code review.
> Next step is to add the Registrator method.
>
>
> -----------------------------------
More information about the clam-devel
mailing list