The current plan

As of now, it is too early to define the structure of the whole framework in all of its components. The most important thing to do, instead, is to build a solid base for its development.

So, in the first development cycle (from the first development release to the first stable release) we will limit ourselves to the building of only three components: the NASPRO core library, the NASPRO objects library and the NASPRO objects modules collection of modules for the NASPRO objects library.

Here follows a very short description of these components, just to give a general idea of what each of them is for. More detailed descriptions can be found later on in this document.

The NASPRO core library

It is the inner part and the foundation of the framework. Roughly speaking, it serves three purposes: interfacing to the operating system, help in building modular systems and make it possible to exchange some particular kinds of data among the various parts of the framework and the application.

The NASPRO objects library

This library is, obviously, based on the NASPRO core one and is in charge of handling the functional part (sound processing, synchronous/asynchronous ports, parameters, etc.) of sound processing objects (regular plugins or sound processing components in other forms). As you can easily imagine already, each format is supported via external modules.

The NASPRO objects modules collection of modules

This is a collection of modules for the NASPRO objects library. Each of these modules implements the support for a given format for the NASPRO objects library itself.

Future directions

Here is a list of possible components which could be developed for future versions of the framework:

• a library to connect an unlimited number of instances of sound processing objects in a graph-like fashion, even with feedbacks, and allowing dynamic composition and optimization (much like what CLAM already does);
• a collection of converters and utility objects for different kind of streams/signals;
• a library to support GUIs bundled with many plugins around and support for toolkit-agnostic autogeneration of GUIs;
• new data-based non-algorithmical formats for sound processing (such as mathematical formulas, circuit diagrams, neural networks and transfer functions);
• a library to support session management (see LASH);
• a modular and portable library to perform audio I/O with a single API (as in PortAudio, more or less);
• a system to support online help for sound processing objects;
• a system for internationalization and localization of sound processing objects and their GUIs;
• expand NASPRO core to become as feature complete as a regular portable runtime like GLib, Netscape Portable Runtime or Apache Portable Runtime;
• support in part or in the whole framework for scriptable and/or special-purpose languages like Matlab/Octave, R, PureData, nova, etc.;
• find the way to use NASPRO in embedded applications;
• a portable and integrated system to download, install and maybe even purchase, sound processing components from the Internet;
• a system to analyse and maybe even try to auto-reproduce real world filters;
• a system to generate traditional plugins from networks and/or non-algorithmical processing components;