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

[Pau Arumi]

En/na Stefano D'Angelo ha escrit:
 >
 > 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:

no problem.

 > 1. use of CLAM for C-written hosts: is that possible?

no. well, it doesn't make sense to me (at least for what i
understand a host is in clam). to host, say, ladspa plugins we
have added *only* the following ladspa specific code
1- code to examine all available plugins (in standard dirs) and a
data-type to store this info.
2- code to instantiate a given (by the user) plugin under a
generic factory interface.
3- the ladpawrapper class: a processing that dynamically creates
ports and controls mapping those of the plugin and whose Do()
delegates to the plugin "process" function.

all this is very light-weight but all three points interacts with
clam C++ objects (processing, factory...) so it should be C++.
compared to "traditional" hosts, this is so light-weight because
we relay on processing network and audiosources/sinks for the
important stuff, like audio routing, a host must undertake.

an idea that bounced in my mind some time ago is that we could
have different different kind of networks (much less flexibles in
port sizes, for example) and specialized flow-controls. but
that's (maybe) another story.

 > 2. modularity: are you going to hard-code each plugin standard wrapper
 > in CLAM or use external modules?

as part of clam_core by now.

after clam 1.0 (due very soon) we'll be focusing a lot on
extensibility. that basically means have all processings and
audio back-end as plugins. so clam_core is simpler, and
processings are easier to write and integrate for other
developers.
 
however, i think its wiser to start simple and split modules only
when the advantage is apparent (yes, enabling parallel
development *is* an advantage).
but given the ladspa experience, and the fact that the number of
wrappers is not meant to grow very much (like plugins do) or have
other dependencies (like audio backends do) i don't really see
the need right now.
but maybe you'll give me reasons to convince me of the contrary.

 > 3. embedding: will it be (or is it) possible (or to say better,
 > convenient and efficient) to use CLAM in embedded applications?

not sure what you mean:

- "embed clam in applications": sure it's really straightforward.
  you just need to instantiate a networkplayer, choose the backend,
  load the clamnetwork file, and run the networkplayer.

- "clam in embedded systems" well, clam use floating point.
  (float or double is configurable) this is a limitation in some
  embedded systems.
  on the other hand clam_core do not (or not mandatory should)
  depend on many libs if any at all. and you can add other
  components as needed.

actually, as i said, there is some work to do to make clam more
extensible. this includes moving processings in core to other
libs/plugins.


cheers!

pau