[Clam-devel] new plugin load logic of the ProcessingTree

David García Garzón dgarcia at iua.upf.edu
Wed Jun 27 05:56:55 PDT 2007


On Wednesday 27 June 2007 13:55:12 Pau Arumi wrote:
> En/na Andreas Calvo ha escrit:
> > With the old LadspaFactory, the load of LADSPA plugins was done using a
> > LadspaPluginExplorer, which function was to search in some directories
> > for plugin libraries, and then return a list of a structure of plugins.
> > So the ProcessingTree just received the list and inserted the plugin
> > into the LadspaFactory instance.
> >
> > Now, since the same factory can handle all kind of plugins, this logic
> > needs to change.
>
> To be precise --i guess we agree-- the logic that have to change is
> this: instead of filling the processing-tree using the
> LadspaPluginExplorer output (list of strings), we should 1. put
> everything (processings, ladspas...) on the PFactory, and 2.
> construct the tree using the PFactory content. (and this needs
> metadata to organize the hierarchie)
>
> > This involves two steps (in my opinion):
> > First, we need to add some metainfo to the plugin in the moment we're
> > inserting into the Factory. Most obvious metadata is the category of the
> > plugin. But this need some background too, and it's related to the new
> > ProcessingFactory, which is gonna be the container of the plugins and
> > their category. So it is necessary to map one object with one category,
> > and to be able to export categories and relation between objects.
> > Once the ProcessingFactory can return some lists based on the category
> > they belong, the processing tree logic can change: create the tree based
> > on the category of the plugin.
> >
> > So, in a more simple way, the ProcessingTree just retrieve data, it
> > doesn't insert anything.
> >
> > Moreover, I've been thinking that maybe it is necessary to add some
> > method to remove a specific plugin from the factory (this is most
> > related with the way Faust is handled).
>
> Agree. To remove any processing given its key. Actually this should
> go to the Factory<> base class.
>
> The other day, David was proposing this interface to initialize
> metadata of a processing (I'm using dummy data here):
>
> static FactoryRegistrator<ProcessingFactory, MyProcessing> reg = {
> 	"key", "MyProcessing",
> 	"type", "Modulation/Chorus",
> 	"vendor", "UPF"
> 	}

I know the proposal is mine but we could also use just the vendor/key pair to 
locate in a richer non-hardcoded database in files.


> the registrator could internally add other tuples (i.e.
> ("architecture", "clam processing") or ("doc",MyProcesing::GetDoc()) )

You cannot call MyProcessing::GetDoc here. I think you can if you when using 
parameters of a constructor, but not as a constant field.

> I guess, the main difficulties here are:
> * How to contruct a QTree using the "type" attribute info
> * Implement this interface (in case we want it)
> factory.GetListOfKeys("type", "*Chorus*");
>
> So let's start hacking :)
> pau
>
> _______________________________________________
> 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