Fwd: [Clam-devel] CLAM and NASPRO

[Pau Arumi]

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.

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.

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

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

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

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

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)

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


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

regards,

pau