[Clam-devel] CLAM and NASPRO

Stefano D'Angelo zanga.mail at gmail.com
Thu Mar 1 11:09:07 PST 2007

2007/3/1, Pau Arumi <parumi at iua.upf.edu>:
> En/na Stefano D'Angelo ha escrit:
> >>
> >> 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).
> i'm not interested at all with that kind of efficiency improvements in a
> plugin host. all hosts see plugins as black-boxes and that why they are
> successful, imo.
> i don't even think that many typical plugins are really LTI filters. but
> anyway, why don't you see this as a toolkit for compiling plugins, managing
> a set of white-box algorithms. this would make sense to me. but a host
> is another story.

Optimization is not always related to LTI filters... the concept I'm
talking about is a bit wider, that could be one thing.
Take it this way: what if plugins know how to "merge" them with other
plugins (which is equivalent to saying that they give some functional
representation of what they do to the host - see below)? As someone
said on the LAD, it would be like overriding the + operator in C++.
Then... I'm not willing to write a host or a new standard! I'm going
to basically develop a library!
So when I was saying "host" before, I was referring to the library,
which does that for the host.

> > 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.
> standards are all about having people to use them. now that the LV2 is
> in its definition stage, i don't think that proposing a new standard will
> help you to have more users. why not try to convince the LV2 proposers
> that you have a better idea? and *specially* providing working examples
> and extensions.

Again... I'm not proposing a new standard, I'm offering a way to use
existing ones!
The "two ways" are two ways of solving the problem, since LV2 authors
have addressed the same issue, but I do not agree with them that LV2
extensions are valuable as a solution.
Personally, I do not even agree that plugins should implement
functionality which has nothing to do with their natural task of
processing sound (GUIs being an example), but anyway that's how it
goes right now.
Here you see the diffence: in LV2 plugin authors are encouraged (or
helped) to put new stuff into plugins via extensions, in NASPRO
they're encouraged to work exclusively on the DSP part, and if they
miss a feature, they can implement directly in the library itself, via
modules, so that it becomes available to everyone.

> >>  > 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)
> well, you can do a network as simple as you whish.
> i think this is quite good:
> net.AddProcessing("AudioSink");
> net.AddProcessing("AudioSource");
> net.AddProcessing("VST/PhatCompressor");
> net.ConnectPorts("AudioSource.out", "VST/PhatCompressor.in");
> net.ConnectPorts("VST/PhatCompressor.out", "AudioSink.in");

Just an idea, however that's quite nice.

> >> - "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).
> i disagree here. what clam is most ahead is in the wrapping thing.
> the wrapper is a processing object that gets configured with a given plugin.
> mapping plugins properties to the PO and have a running system with a
> PO network is the hard thing.

So I would say: how much is CLAM ahead in "mapping plugins properties
to the PO" with different APIs, since that's the fundamental part of
what I'm working on?

> > 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?
> as said in my previous mail, all "host" related code is very C++. it
> could be
> seen as a (separate) layer but it have contact with:
> - processing-tree and factory: to organize all instantiable processing
> objects
>   and plugins
> - processing-object that wraps the actual plugin.
> separate this in a independent module is not obvious at all for me at this
> stage. if there's a singe think we have learned during the 6 years of clam
> development is that big-up-front-design is evil. of course you are
> welcomed to
> make an api proposal for such modules, and/or send patches to go into that
> direction (we always pay a lot of attention to patches!).
> but my plan is to go the safe way of iterating "add small functionality
> - refactor"
> over and over.  and maybe at some point the code call for a "extract
> modules" refactoring.




More information about the clam-devel mailing list