[Clam-devel] Exporting CLAM Processings as Ladspa plugins

David García Garzón dgarcia at iua.upf.edu
Mon Jul 7 12:49:01 PDT 2008


I have been revisiting the mechanisms in clam to build a LadspaPlugin. I 
noticed that ProcessingClass2Ladspa sources were blacklisted and so were the 
examples. So 'fix or remove!' and this time i fixed. Such class is about 
converting Processings into plugins, and although our plan is doing such a 
thing with Networks, i considered cleaning up that interface a nice exercise.

At the end you can define your plugin just by doing this:

----- MyLadspaPlugin.cxx
#include "AudioMultiplier.hxx"
#include "Oscillator.hxx"
#include "ProcessingClass2Ladspa.hxx"

static CLAM::LadspaLibrary library;
extern "C" const LADSPA_Descriptor * ladspa_descriptor(unsigned long index)
{
    static CLAM::LadspaLibrary::ProcessingExporter
		<CLAM::Oscillator> a1(library, 3000);
    static CLAM::LadspaLibrary::ProcessingExporter
		<CLAM::AudioMultiplier> a2(library, 3001);
    return library.pluginAt(index);
}

This has several benefits from the blacklisted version:
* You can define multiple plugins types in a single dll
* You don't have the undefined 'Instance' linker error by including the 
functionality on the library so that the generic code can be back to clam 
core without blacklisting
* Several CLAM based ladspa libraries loaded in a single host don't collide
* The library mechanism is general, based on inserting LADSPA_Descriptor 
structures into the LadspaLibrary, so we could easily add an object that 
inserts descriptors for Networks, the initial goal.
* Template code has been reduced nearly to NULL

Some noticeable changes:
* I added "CLAM_" and "CLAM " prefixes to the plugins name and labels.
* Bug squashing (buffer allocation, reinstanciating, leaks...)

Some work is still needed to clean up the internal implementation but the API 
shown above is pretty nice and ready to become stable (and moved back to 
core), so i wanted to ask you for API preferences.

* Do you like ProcessingExporter being an inner class, or it would be better 
having a CLAM::LadspaProcessingExporter? 
* Names? We should avoid conceptual clash with classes to load ladspas as 
host.

(The former class ProcessingClass2Ladspa has become a hidden implementation 
detail and very likely to be changed/splitted/renamed/removed on next 
refactorings)

David.






More information about the clam-devel mailing list