Fwd: [Clam-devel] CLAM and NASPRO

[Stefano D'Angelo]

2007/2/28, Pau Arumi <parumi at iua.upf.edu>:
> En/na Stefano D'Angelo ha escrit:
> > In reply to this (and the other mail you sent), I have to say I would
> > be very happy to contribute code to CLAM, but, of course, I need some
> > time to take a look at it, play with it and figure out how things
> > work. I do count on your help in this task.
> >
> > Anyway, you pointed out that we can collaborate on code level at both
> > projects, and that'd be fine. But maybe it's the time to talk about it
> > since I'm reworking on NASPRO implementation since less than a week
> > ago (I did a first attempt two or three weeks ago, than chose to
> > restart splitting the whole thing in 4 libs), so I'm still "fighting"
> > with basic stuff like module loading, ADT, error handling, autotools,
> > etc. and a "migration" wouldn't be that hard and/or time consuming.
> > As I already said to David in a private mail, I'm doing all of this in
> > pure C (C89, doxygenated, GNU coding style conformant code) since I'm
> > more familiar with it and since it shouldn't be that hard to wrap in
> > C++.
> > But there's also the possibility to directly switch to C++, or maybe
> > even to make NASPRO become a part of CLAM, I would have nothing
> > against it.
>
> hi stefano,
>
> i think it would be more useful start discuss on naspro and clam
> concrete goals and how we want to achieve them.
> you know david and me are currently very busy doing improvements and
> fixes for clam 1.0, so i won't be exhaustive in the list.

Right.
Here's part of a private mail I sent to pnpd's author Tim Blechmann
which could clear up thing somewhat (we were talking about FreeADSP,
my original project):

---

The website is quite outdated since we're working on a new one :-)
Anyway, FreeADSP will "just" be a "software pedal board" which will
let you connect different processing objects (aka plugins) in a
network-like fashion (much like Om - Ingen).
The good thing about it is that it will be capable of changing presets
(networks) in real-time and let you use external devices (MIDI
footswitches, etc.) to interact with the processing objects or with
the program itself (start/stop, next/prev preset, next/prev bank,
bypass, etc.)

Since a lot of plugins around are VST(i) I considered whether I should
use LV2 and use some bridges for them or otherwise use a modular
compatibility layer.
LV2 is good but there is a trivial problem with it to be able to wrap
VST: I call it "logical compatibility", in the sense that they use non
compatible metaphors (you would have to use a bunch of extensions to
make this possible).

So I decided to develop an API wrapper (I called it NASPRO) and
suddenly realized that great improvements could be made over the
classical processing paradigm: first of all, examining the network
topology and using SFTF/z-transform/whatever (given by processing
objects) you can reduce processing time (sometimes by a great amount),
than one could abstract also the generation side of such processing
objects, to help projects like yours, FAUST, etc. but also others like
CLAM.

Then, thinking a little bit ahead, NASPRO could be a useful weapon in
the hands of the free software movement to put pressure on Steinberg
to free up their VST standard.

---

So NASPRO's first goal is to build up a superset API of already
existing plugin APIs, not to introduce a new plugin format, but to
wrap them all ensuring a correct "metaphor compatibility layer" (hence
correct handling of all formats) in the sense of _using_ plugins.
Each format would be handled by a single module (ex. one for
DSSI/LADSPA, one for LV2, one for VST, etc.)

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

> these are some goals and concrete tasks in our "plugins" area. take them
> as a first draft, i'd like to keep refining them and evolving them at
> the wiki and incorporate them into the general roadmap:
> http://iua-share.upf.edu/wikis/clam/index.php/Devel/Plugins_TODOs
>
>
> == improve clam general infrastructure ==
>
> * enhance network flow-control (we are currently working on it).
>  flow-control is a plugable entity in charge of scheduling processing
>  execution. not an obvious thing to do since clam processing allow any
>  port (buffer) size.

This is non-trivial for NASPRO too (see above).

> * dynamically load processings (like as if they where just typical
>  plugins)

What are processings?

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

???

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

> === new plugins-hosts ===
>
> * host ladspa in mac (we should be ready for that)
> * host ladspa in windows (see if someone have already compiled ladspas
>  as dlls)
> * host lv2 [andreas]
> * (maybe faust? does it have a generic interface? or through ladspa?)

About this, Tim told me:

---

otoh, for pnpd, i've been thinking of adding the functionality to run an
instance of pnpd inside a plugin environment. from the point of view of
pnpd, it's basically another audio backend to implement (beside
portaudio),

---

> == improve plugins creation infrastructure ==
>
> * refactor network-player-back-ends (such as jack, portaudio, ladpsa)
>  classes to avoid code repetition. now we have a subclass for each
>  back-end.
> ** david thinks the could would be cleaner and more usable having a
>   single network-player class with plugable back-ends.
> ** the refactoring include better class naming and move sources at an
>   appropriate dir.
>
> * better SConstruct for compiling network-players into plugins  (.dll,
>  .so)
> ** improve the way to specify and install the clamnetwork file
>
> === new plugins architectures ===
>
> * vst (license issue)

See below

> * generate vsts with clam-prototyped gui [work in progress: pol]
> * vst for mac
> * dssi with clam-prototyped gui
> * others?
>
>
> = DONE =
>
> * experimental ladspa host in linux
> * generation of ladspa plugins under linux (needs some refactor)
> * generation of non-gui vst under windows (needs some refactor)
> * standalone apps with prototyped-gui (using qt4 widget plugins)
>
> >
> > There may be however some downsides in doing this last thing (you'll
> > tell me): dependencies and, consequently, adoption.
> > You know, this last point is one of the most important for such a
> > project. I imagine that a lot of "purists" out there would much prefer
> > to work in C with a bunch of little libraries, each with a different
> > aim, and some others would prefer to use higher languages (apart from
> > C++) and that could be done with SWIG.
> > 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.

> though clam could be seen as a plugin-host (network+network-player) and
> plugins libs (processigs) clam is not meant to be *another* plugin
> standard. i remember david stressed that out at linux-audio-dev.
> also, clam model and implementation is very object oriented, so writing
> a (native) clam processing means writing C++ (of course you can always
> write, say, a ladspa plugin and use it in clam)

As said before, can you explain more in detail what such "processings" are?

> about python, we xavier said we want do clam python-enabled. but i don't
> see clearly how this fit with the plugins area.

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.

> > Then a last issue: I'd like to release NASPRO under a "weapon license"
> > which lets developers link it against proprietary programs, while only
> > the "use part" of modules can be proprietary and the
> > "generation/composition part" must be free. (I've asked to GNU
> > licensing support, I'm waiting for their response).
> >
> so it would be interesting to know the details: what are those naspro
> modules,
> and in general what are naspro/your technical goals?

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.

Cheers,

Stefano