[NASPRO-devel] Re: LibIntegra/NASPRO common goals

  • From: "Stefano D'Angelo" <zanga.mail@xxxxxxxxx>
  • To: naspro-devel@xxxxxxxxxxxxx
  • Date: Fri, 4 Apr 2008 14:18:20 +0200


2008/4/4, Jamie Bullock <jamie@xxxxxxxxxxxxxx>:
>  Hi Stefano,
>  Sorry for the slow reply.

I thought you'd never reply ;-)

>  On Sat, 2008-02-09 at 12:13 +0100, Stefano D'Angelo wrote:
>  > Just finished my exams. I haven't read the LibIntegra paper yet, but
>  > from what I see on the website, it seems like the focus is on remotely
>  > storing and retrieving plugins' meta-data (correct me if I'm wrong).
> Kind of. The Integra concept revolves around 'modules' which are
>  abstractions of some kind of processing unit. These could be 'plugins',
>  but not necessarily, they could equally be Max/MSP or Pd objects,
>  SuperCollider classes or even standalone applications. An Integra module
>  consists of three things:

That's exactly the same thing I'm doing in NASPRO. I have "processing
objects" which can be plugins, but also anything else.

In fact this year NASPRO partecipates to Google Summer of Code as part
of the atheme.org organization, and one of the proposed ideas looks
like this:

"Design a file format to store FIR and/or IIR filters' time response
(together with some generic information) and write, to some extent, a
NASPRO objects module supporting it."

Which means that the processing object in this case is nothing but the
impulse response data in itself. What is reference as a "module",
instead, is the actual implementation of the standard for the NASPRO
objects library (which loads support for standards from these external

>  - The module definition: this defines the *interface* of the module,
>  i.e. its namespace, parameter data types, units, ranges of values etc.
>  - The module implementation: the implementation of the module's
>  *functionality* in a given environment
>  - The module instance data: this corresponds to the *state* of a modules
>  parameters at a given moment in time
>  The purpose of the Integra library is to facilitate the loading and
>  saving of modules and intercommunication between them. Module
>  definitions and instance data can be saved to XML files or an online
>  database. Module implementations can also be stored in the database
>  along with the module definitions.
>  The requirements for instantiating a module in a given environment are
>  that there must exist an implementation for that environment AND a
>  *bridge* to facilitate communication between the environment and the
>  Integra library. We currently have working bridges for Pure Data and
>  Max/MSP. I am Interested in NASPRO, because AFAICT, if wrapped as an
>  Integra bridge, it would enable the Integra library to instantiate a
>  range of plugin types.

Same here (apart from the XML/database thing). Plus, I'm also working
on *back-bridges*, which are standard-specific plugins using NASPRO to
access all other processing objects in the system and, at the moment,
I'm finishing support for LADSPA and Audaciuos' effect plugins.

I could also make an Integra module for NASPRO objects, which would be
specular to what you're doing, but... we would be wrapping wrappers!

I suspect that merging the two projects is out of discussion as of
now, but what I intended to say is that we can work together on parts
we both care about... read below.

>  > If I'm right, then the first obvious common goal our two projects have
>  > is the categorization of such meta-data (Integra), thus the plugin
>  > representation/abstract model (NASPRO objects).
> How concerned is NASPRO with this? Don't you just get the plugin
>  meta-data from the plugin itself via Introspection? i.e. in LADSPA terms
>  from the plugin descriptor/port hints.

Yes. But that doesn't imply a weak "it's good if it works" abstract
model for processing objects. In other words the NASPRO API must be a
clean and well-structured superset of plugin/whatever APIs available
around and must work perfectly with them.

For example the Audacious fx plugin API and LADSPA have two different
approaches to represent channels: in the first one there is only one
port and all data is made of interleaved samples, while in the second
each port has only on channel. How to make them work together? Two

1. Adopt one of the models;
2. Make a superset of the models.

I chose #2, and now in NASPRO objects each port can have n channels
connected to it. I hope it's needless to say that it works with both
APIs. :-)

>  > If you're interested in having some discussion and exchange (hopefully
>  > collaborative in both ways - I help you, you help me, possibly for
>  > coding too), please tell me what's the most appropriate place to start
>  > talking about it.
> Personally I think that we should let both projects evolve in parallel
>  at first. I can't see very much overlap between the projects (which is a
>  good thing), and if they continue to develop roughly as they are, then
>  they could work well together at some point in the future.

Well.. we could start sharing our solutions (in human language) to
some of the problems we encountered in our ways. I'm actually thinking
about developing a common abstract model (in human language, again)
for all sound processing APIs around, trying to find the best
solutions to problems like the one I mentioned before.

>  > We could also talk to and involve other people interested on the
>  > subject of course (plugin API authors, Faust?, someone else?)
> Yes definitely. I am thinking that too, but I think the Integra project
>  needs to produce more tangible results before we start collaborating
>  with other projects.

That's true for NASPRO too. Hope to make a first release before May
(and probably I have to) ;-)

>  Still I will be watching NASPRO carefully to see the progress.

That's fine. Perhaps I already asked you... do you have a mailing list
or a place of discussion for libIntegra? I want to follow your project
as well.

Best regards,


Other related posts: