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

[Pau Arumi]

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"
	}
the registrator could internally add other tuples (i.e. 
("architecture", "clam processing") or ("doc",MyProcesing::GetDoc()) )

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