[Clam-devel] CLAM and NASPRO

[Pau Arumi]

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