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

[Stefano D'Angelo]

Again again and again: GMAIL IS INCREDIBLY DUMB!!!! Sorry :-(

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


2007/3/1, Pau Arumi <parumi at iua.upf.edu>:
> 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.

I was intending in the sense of embedding clam in C-written host
applications... this could be a wise thing: see below.

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

Yes I'm going to do that (repeating some basic stuff since it could
make you understand better what I mean) :-)
All plugin APIs have one thing in common: a function that takes some
input and throws out some output (as well as inputs and outputs lists,
etc.).
Then they build around such "functional core" all the bells and
whistles (logical metaphor, GUI handling, session storing, etc.) which
really makes them incompatible between each other (you can always
build bridges but the result usually does not have 100% functionality
of "the original implementation").
The way which all such APIs (I know of) work is by an exclusively
algorithmic core, which the host application doesn't know about. It
just feeds input and takes output (plugins are a black box).
As I and other people pointed out, there's a big margin of improvement
that can be made by letting the host know about the real plugin
functionality (once again: SFTF/z-transform/zeros and poles etc.),
especially if they are arranged in a network. For example all
subsequent LTI filters can be "merged" in only one filter knowing
their transfer function (a practical case: an equalizer and a delay in
series).
No plugin arch is currently capable of taking advantage of such
things, apart from LV2 via extensions (see below).
In this prospective, there is also the possibility to replace the
current "plugin fashion" with other kind of files which could be more
manageable and easy to develop (text, XML, etc.)
Getting back to different plugin arch features, there's also the
possibility to supply externally features which a given standard
misses (for example session storing for DSSI/LADSPA).

How to do all of that?
Two ways:

1. build a new extensible API. And that's LV2.
What's wrong with it? In my opinion the extension system since it does
not solve compatibility problems, it creates new ones!
What if there will be two extensions that do the same thing with some
little difference that makes them incompatible? Either one "wins" or
it becomes a new issue! The same old story.

2. implement an extensible wrapper. And that's NASPRO.
Why should it be superior?
a. It's not going to be a "floating standard", but a solid
implementation. Developers do not need to reinvent the wheel, and
people who want to experiment with a new API or to bring new features
to an existing API just have to write (or modify) a module, and that
will work on any NASPRO host. The same goes for people who are
creating new formats which are not based on dynamic modules (this
could have a great meaning in the research field).
b. modularity often means consistency, since module developers are
forced to use a standard API to accomplish their tasks (of course I'm
not saying that hard-coding implies writing a mess, but sometimes
there's such tendency)
c. again, knowing about the network can bring to optimizations, and in
this case these could be done by NASPRO itself, maybe together with
its modules. (I still haven't found out how to do this in a "standard"
way).

So, coming back to the original question: modularity brings the
features of letting non-hardcore developers easily extend your work,
let them experiment and play with different ways of doing the "same
old task", and, last but not least, raise interest to your project.

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

I meant the second one :-P

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

What about not forcing application developers to use clamnetwork files
and the network paradigm? Maybe they just want a robust plugin
wrapper/implementation (I'm honestly thinking about NASPRO :-P)

> - "clam in embedded systems" well, clam use floating point.
>   (float or double is configurable) this is a limitation in some
>   embedded systems.

Not a big problem, I think.

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

That's fine. But audio backends are not part of clam_core?

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

That's fine too.
Here I make a proposal: I have the impression that we're going towards
the same direction but from different point of views (which does not
imply that the approach should be different).
It seems to me that what NASPRO is about is at a lower level than
CLAM, and that it could bring great enhancements to CLAM itself (maybe
I'm a bit pretentious).
So we're going to do basically the same work, and it really makes no
sense to work each on its own. CLAM is a great and successful product
and its development is very ahead of my tiny NASPRO, but with the
"wrapping" task we're almost at the same point (I've just completed
the module loading part, you have experimentally implemented LADSPA
support).
In my opinion we could go this way: make NASPRO become part of the
CLAM project, but keep its code separated from CLAM itself (I leave to
you answers to technical issues like using  CLAM data types in NASPRO,
etc.), maintain C support in NASPRO and build C++ bindings for it to
be used in CLAM, maybe develop a C interface for CLAM, and let it
contain all network-related stuff. In other words, NASPRO could become
the "wrapping part" of CLAM, and could be used on its own when network
is not requested by the host application developer.
What do you think about this?

Stefano