Fwd: Fwd: [Clam-devel] CLAM and NASPRO

[Stefano D'Angelo]

sorry again.... gmail is REALLY DUMB!

---------- Forwarded message ----------
From: Stefano D'Angelo <zanga.mail at gmail.com>
Date: 28-feb-2007 20.51
Subject: Re: Fwd: [Clam-devel] CLAM and NASPRO
To: Pau Arumi <parumi at iua.upf.edu>


2007/2/28, Pau Arumi <parumi at iua.upf.edu>:
> 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.

ok

> > 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)

ok

> > 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)

Well, in VST for example, chunks are only data associated with each
plugin that the VST library loads/saves for them (I don't know if
they're also associated with a specific host or not).
I didn't even start to think on how to do that, but anyway it could be
a quite useful feature also for other plugin standards, and can be
done without breaking them.
>From the point of view of a complicated host, like my FreeADSP, it
would make sense to store all input control values for each preset
(aka network), the presets topology and the "banks" organization (1
bank = n presets).

Regarding library splitting, maybe it's not that useless: a media
player for example could discard the use of such a "general purpose"
and complicated thing.
Also Paul Davis said on the LAD ml:

"find me a host author who would want to use such a thing... managing
plugins is a central task of a host, and handing that over to some
"wrapper" that hides information from the host doesn't make the host's
life easier, it makes it more complex."

While I think he probably hasn't understood what this is all about,
however the "you must use networks" approach might not be the right
one.

> > 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!

See below.

> >
> >> * 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

Ah, ok. I didn't know your terminology, I call them "processing objects".

> >> == 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.

ok

> >> * 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)

ok

> >>  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.

It depends on how many people are going to use 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".

Yes, I see. That's why I'm 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.

As I said, I'm not against this and I'm also considering this opportunity.
In the case that I will join in CLAM, there are some things I'd like to know:
1. use of CLAM for C-written hosts: is that possible?
2. modularity: are you going to hard-code each plugin standard wrapper
in CLAM or use external modules?
3. embedding: will it be (or is it) possible (or to say better,
convenient and efficient) to use CLAM in embedded applications?

I'm sorry to say this, but if I don't feel we're going the same way, I
don't think there's any possibility for me to stop working on NASPRO
and go on with CLAM.

2007/2/28, Xavier Amatriain <xavier at create.ucsb.edu>:
> Stefano, Pau, I like the direction the discussion is taking!

Me too :-)

> As Pau knows there are many possibilities of us getting a Google
> Summer of Code. We should definitely prepare one of the projects
> along these lines and invite Stefano to apply.

That would be great, but anyway see above.

> Stefano, are you enrolled in any formal education institution?

Yes, I attend the second year of Computer Engineering at the
Politecnico di Torino.

Cheers,

Stefano