Fwd: [Clam-devel] CLAM and NASPRO

[Stefano D'Angelo]

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


2007/2/26, Pau Arumi <parumi at iua.upf.edu>:
> Hi Stefano,
>
> Thanks to show up in the list and present your project. It's true that
> we share many goals, and indeed we all should take advantage of this.
>
> Actually, since our projects are GPL, I think the best would be to
> cooperate at the code level. Probably it's premature do discuss how to
> do that. To start, I'll try to do a very quick summary of what we have
> in CLAM that might interest you. More details on demand.
>
>
>
> == Plugin generation from a CLAM network ==
>
> - How it works? In short: using a blocking-network-player object.
>
> - A CLAM network is a processing container object that can be visually
> edited with NetworkEditor.
> a NetworkPlayer object knows how to execute the network driven by an
> audio back-end. Some of them are plugin architectures and others not. We
> currently support jack, alsa, portaudio, LADSPA and VST.
>
> - In order to generate a plugin, the network must provide audio and
> control entry points. We do that using AudioSource, AudioSink,
> ControlSource and ControlSink.
>
> - ControlSource can be configured with range and units parameters that
> will be exported to the specific plugin definition.
>
> - CLAM Networks uses a very flexible buffering schema. Processings can
> require to read a certain buffer size and all this is handled
> automatically. Similarly, the plugin host (or audio back-end) can
> provide any buffer size to the network. Of course, processings that
> needs buffering (fft) will cause a delay.
>
> - Such plugins (VST or LADSPA) can be compiled with a hardcoded network,
> a hardcoded network file, or using an environment variable pointing to
> the network file (this only works for LADSPA)
>
> - The status of all this is quite experimental, but we are currently
> working on this. Pol Pros is a student working on VST plugins. He is now
> focusing on having VST plugins with QtDesigner gui. Like we have for
> stand-alone apps. (See the NetworkEditor tutorial in the wiki
> http://iua-share.upf.edu/wikis/clam/index.php/Network_Editor_tutorial)
>
> - Look at the code. As said it needs some refactorings but the direction
> is already very clear :
>  -- NetworkEditor/src/vst/TestPlugin.cxx
>  -- CLAM/examples/NetworkLADSPAPlugin/NetworkLADSPAPlugin.cxx
>
>
>
> == Hosting plugins in a CLAM Network ==
>
> - How it works? loading plugins and wrapping them into a processing.
> This wrapper publishes the plugin ports through CLAM Processing ports
> and controls.
>
> - We currently support LADSPA. Quite experimental but evolving very
> fast. Andreas Calvo is in charge of this.
>
> - Code examples: we have some old-wrappers-code but better hold on a
> little till Andreas send us his patches with revamped . Hello Andreas!
>
>
>
> Btw, past CLAM developers (students) that contributed code on those
> topics are Xavi Rubio and Xavier Oliver.
>
> Feel free to ask any doubt or, better, jump in and hack into that CLAM
> infrastructure, send patches, share your "vision", etc. You'll see that
> we like working as a team.
>
> Cheers!
> Pau
>
>
>
>
> En/na Stefano D'Angelo ha escrit:
> > Hello everyone,
> > some of you already know me, I'm Stefano D'Angelo, an Italian
> > university student who is willing to develop a toolkit for sound
> > processing applications which can wrap existing modular processing
> > APIs (LADSPA, LV2, VST, DSSI, etc.) both for use and for generation of
> > such plugins.
> >
> > As pointed out by David, our two projects may share some points, so
> > maybe it would be fine to cooperate someway or at least to keep in
> > contact.
> >
> > If you don't mind I'll keep you informed on how my coding is going and
> > on relevant news.
> > Right now I set up a project page on Sourceforge, from which you can
> > already take a look at the code I already wrote (a few lines of code
> > right now)... a website will come sooner or later.
> >
> > Look forward to hearing from you,
> >
> > Stefano
> >
> > _______________________________________________
> > Clam-devel mailing list
> > Clam-devel at llistes.projectes.lafarga.org
> > https://llistes.projectes.lafarga.org/cgi-bin/mailman/listinfo/clam-devel
>
>

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.

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.

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

Let me know as soon as possible,

Stefano