About NASPRO

NASPRO, recursive acronym for "NASPRO Architecture for Sound PROcessing", is a free, powerful, reusable, modular, real-time capable, thread-safe, scalable, standard-agnostic, cross-platform framework for digital signal processing, especially focused on sound processing.

Its main aim is to give audio application developers a full-featured, yet scalable, high-performance and integrated tool to make use of virtually any external sound processing component (including, but not limited to, LADSPA/DSSI, LV2, VST, AudioUnits and DirectX plugins) via a single, fully transparent and platform-independent API.

So, an application using NASPRO will be capable of running simultaneously and exchange data among sound processing components which would be normally incompatible, without even having knowledge of what kind they actually are.

And this is just the tip of the iceberg!

What's new about it?

What's actually new about it, when compared to other pieces of software trying to solve the same task, is its layered modular design.

Modular means that instead of having knowledge on how to handle different formats internally, it relies on external dynamically loaded modules for this purpose. In practice this means that support for new formats does not require modifications to the source code (from an user's point of view: no upgrade, just install a module - in this sense, it is to sound processing components like what GStreamer is to audio/video files or Imlib2 to image files), and that it is possible to develop new formats for non-coded and/or non-algorithmical sound processing components (for example mathematical formulas, simulated electronical circuits, neural networks or Fourier trasform data) bypassing the interface of a given plugin format.

Layered means that it is made of several components, each dealing with a specific aspect of the whole problem (basic functionality, GUI, data chunks, etc.), possibly having one or more classes of external modules and reusing lower level components of the same framework. This introduces the possibility to develop format-independent features and/or reuse capabilities of a given format for processing components into other formats (for example use a VSTGUI interface for a LADSPA effect); plus, applications can also use only part of the framework if they don't need higher level features.

In a few words: NASPRO aims at becoming the basis for a feature-centric, rather than format-centric, paradigm for sound processing.

Does this mean that you are creating yet another plugin API?

While it is technically possible to implmement sound processing components directly based on the NASPRO API, it is considered a really bad way of using this tool, since it would be counterproductive for the adoption and for the goals of this project. There are already too many incompatible APIs around to do sound processing and we are trying to solve the problem, not to extend it.

Anyway, the nature of NASPRO allows us to easily try new possible ways of developing sound processing without the problem of interoperability; in this sense we will probably develop new formats for sound processing components made of data (like, as said before, mathematical formulas, simulated electronical circuits, neural networks and Fourier trasform data) and/or written in interpreted, special-purpose programming languages (such as Pure Data, Max/MSP or Matlab/GNU Octave).

Will it work on my favourite OS?

Yes, if your platform is already supported. Otherwise, it can be relatively easily ported, since it is designed for this right from the start.

In fact it is entirely developed in strict ISO/ANSI C (ISO/IEC 9899:1990, also known as C89) and contains little OS-specific code, which is itself clearly separated from the rest.

This, in contrast to what many people think, helps avoiding the use of cross-platform wrappers to access OS-specific functionalities (which would often result in unneded bloat) and also makes it possible to better adapt it to the underlying system (as in the case of file placing/retrieving policies).

Furthermore, developers using NASPRO can take advantage of the same mechanisms (conditional macros and definitions and OS-/machine-dependently implemented functions) used by the framework itself to gain high portability with very little effort.

The minimum requirements to port NASPRO on a given OS are:

• a C89-compliant C library;
• a dynamic loader.

While, in order to safely work in a multithreaded environment, the C library should be mostly thread-safe (including having a thread-local errno lvalue) and a way to access basic synchronization mechanisms is needed too (whether dealing with userspace or kernelspace threads and via a thread library or via system calls is not fundamentally important).

Practically every modern OS has such features.

N.B.: All of this doesn't mean that you will be able to magically use code developed specifically for a certain OS into another, incompatible one (for example using Windows VST plugins on GNU/Linux will only possible via an external module using Wine, not natively).

Are you sure such a complex thing will actually work? Is it needed at all? And what about performance?

If you're asking yourself such questions you're probably a techie, so you need a techie answer. :-)

As you may have noticed, the whole thing is actually about interoperability (intended as the capability to exchange data among heterogeneous functional units). The Virginia Modeling Analysis & Simulation Center (VMASC) defined the "Levels of Conceptual Interoperability Model" (LCIM) in which six levels of interoperability are documented.

Current approaches to the problem would rank at best at the fourth ("Pragmatic Interoperability") or at the fifth ("Dynamic Interoperability") level of the LCIM, while NASPRO surely ranks at the sixth ("Conceptual Interoperability") level; this is because it uses explicit abstract models, independent from the specific implementation.

Those models are extremely lightweight and simple (at least from a computer's point of view), and have very little impact on performance; so little that the whole framework can be peacefully used for real-time purposes.

If you don't believe me, give it a try!

What's inside it exactly?

The first development release is made of five components (the number will probably grow towards the first stable release):

• NASPRO core library: the low level library in charge of interfacing to the OS, exporting platform-independent symbols and setting up the basic environment on which rest of the framework can be built;
• NASPRO objects library: the library dealing with the functional part of sound processing components (hereby called sound processing objects);
• NASPRO objects modules: a collection of modules for the NASPRO objects library, supporting the most widely used plugin architectures and maybe some cool new stuff;
• NADSPA: NASPRO-to-LADSPA back-bridge;
• Audacious-NASPRO: NASPRO-to-Audacious back-bridge;

I like it, but I'm interested into another field which would benefit from a project with a similar approach. Any ideas?

You're lucky, my friend! :-)

If such a tool doesn't exist yet, you can use the NASPRO core library itself to develop one (or directly use it in your application). In fact it has a very generalistic fashion (does not contain any reference to sound processing at all), is very lightweight and small and makes it relatively easy to build full-featured modular subsystems.

But the interface is C only and I don't want to program in C…

Let us finish the fundamental part of the work, language bindings will come later, when the API is stable enough. ;-)

Licensing terms

It is licensed under the three-clause BSD license, so that you can do almost everything you want with the source code.

Be careful, though, when choosing a license for modules, libraries or applications you wrote using/for NASPRO: only code under the three-clause BSD license is considered for inclusion in the framework itself, while you should in any case avoid the plain GPL, either by switching to the LGPL or by adding an exception clause stating that you except modules, libraries and/or applications linked, dynamically or statically, to whatever part of the NASPRO framework from the obligations of the GPL.

This is an extremely important issue, as better explained here, for end users and software distributors.

Oddities

This project is born out of the FreeADSP project, from the same author (me, Stefano D'Angelo) and, until now, is a one man effort (but this can't go on forever). It was first discussed on the Linux Audio Developers Mailing List (with no much luck, though).

The project name comes from the word "naspro" found in some southern Italian idioms, pronounced nasproh or 'nnashproh. The naspro is a traditional Southern Italian icing used for sweets.