Fwd: [Clam-devel] CLAM and NASPRO

[Pau Arumi]

En/na Stefano D'Angelo ha escrit:
> 2007/2/28, Pau Arumi <parumi at iua.upf.edu>:
>
>
> Then I did some considerations:
> 1. It would be nice to implement also the generation-side of plugin
> handling (aka generation of such plugins - this is maybe the most
> important thing for CLAM).

i think both ways (host and generate plugins) are equaly important for clam.

> 2. Through network representation lots of improvements can be made,
> but since not all hosts require such an advanced feature, it has to be
> split from the "core" NASPRO library. Plugin generation is likely to
> depend on this.

just to make sure you are aware of it: that's exactly how it is in clam.
NetworkEditor is a separated clam application. but the core library can 
load .clamnetwork files edited with the NetworkEditor (or by other means)

> 3. Some features of existing plugin standards are not
> processing-related and are not available on all plugin standards: GUI,
> session storing (VST chunks), extensions (LV2) etc. Again some
> additional libraries can be used to handle this and, even better, to
> make available with plugin systems which do not implement them
> directly.

session equals to clam-network i guess, so we have that covered.
now that we are adding ladspa host into clam_core i see that it is very 
light-weight. i doubt hosts we'll ever "ask" for a split into different 
libs.
(yes, in clam we let "design evolve" and do the simpler thing first)

> 4. (possible ideas for the some near or far future) Integrate the
> whole thing with some dataflow programming language, bindings for
> programming languages other than C/C++, image processing.

hey, you are describing clam!

>
>> * dynamically load processings (like as if they where just typical
>>  plugins)
>
> What are processings?
this:
http://iua-share.upf.es/wikis/clam/index.php/Image:NetEditQt4-WireTargetTooltip.png
processing objects is how we call the modules/ugens/transforms/algorithms
as you see in the NetworkEditor screenshot processings have ports and 
controls. ports are typed (audio, spectrum, tonal, etc).

to learn more about clam:

clam data-flow design patterns
http://hillside.net/plop/2006/Papers/Library/audioPatterns_20060809.pdf

clam meta-model
http://www.iua.upf.edu/mtg/publications/9d0455-icmc05-clam.pdf


>
>> == improve clam plugins-host infrastructure ==
>>
>> * better organization (using meta-data) of NetworkEditor
>>  processing-tree. the processing-tree includes all the loadable plugins
>>  [work in progress: andreas]
> ???
>

nothing special. look this screenshot
http://iua-share.upf.es/wikis/clam/index.php/Image:NetEditQt4-Transparencies.png
the processing tree is the left-side pane organizing the available 
processing objects.
it will incorporate all available third-party plugins, as well.

>> * extend current factory in order to have '''homogeneous plugin
>>  instantiation interface''' [work in progress: andreas]
>
> I don't know how it is for CLAM now, but this is what NASPRO would 
> take care of.

well basically you do ProcessingFactory::theInstance().Create(key)
where key is a processing class name. the TODO means that the factory 
will also instantiate plugins (inside a processing wrapper)

>>  These are my reasons for maintaining NASPRO code separated from CLAM,
>> > but maybe I'm wrong.
>> about C vs C++ :
>> i don't see any issue. plugins standards use to give a C interface. i
>> think this is normal because many reasons. plugins developers adhere to
>> such, typically narrow interface but they can easily program in C++ if
>> they want. you have c++ ladspa examples, for instance.
>
> Yes, but I was talking about NASPRO itself from the point of view of
> host authors, not plugins authors.

ok

>
> In NASPRO this does not fit in the plugins area, which can also be
> text files (in fact I call them "processing objects" and not
> "plugins"). Bindings would be for the use of the NASPRO library in
> hosts.

ok

>
> NASPRO modules are dynamic loaded modules which implement
> standard-specific (non abstract) code. For example we would have a
> LADSPA module which contains info on how to handle LADSPA plugins.
> With the "introduction" of the generation side of plugins and
> non-processing tasks, we could have more modules for a single standard
> (for example one handles the processing part, another session storing,
> another the GUI, etc.).
> I think that forcing people to release the generation side module as
> GPL will put some pressure on Steinberg to free up their standard.

i doubt steinberg will notice anything :-) anyway i can see other 
motivations to do this.

wrapping up, it seems quite clear to me that what you want to achieve is 
something (functionally) very similar to clam. i'd say  that we are far 
ahead on this, and all (my) listed goals are midterm, most of them are 
"almost here".

so what it'd makes more sense to me is to join efforts in clam.  of 
course there are many other things to balance but this is my subjective 
opinion right now.

cheers!

pau