[Clam-devel] CLAM and NASPRO

[Pau Arumi]

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.


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

>
>>  > 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");


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

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

cheers,
p.