Now that we've already talked about the problem and the technical approach we wish to take, we can make a list of goals for this project. Some may seem quite obvious at this point, but it's better to point them out anyway. Here it goes (in no particular order):

1. promotion of technology neutrality and interoperability in the field of digital sound processing;
2. support cooperation among users, developers, distributors and people interested in the project and related external projects;
3. easy and proper portability to the widest possible number of hardware/software combinations;
4. easy reusability of parts or the whole architecture;
5. support as many plugin APIs and related features as possible;
6. support the development of new API-independent features;
7. support the research on new sound processing paradigms;
8. ease of access and use for developers, users and everyone else;
9. high performance and real-time suitability;
10. high quality and valuability of the code;
11. extensive documentation of every part of the architecture;
12. self promotion and acceptance.

Of course some of these goals are long term ones and others might sound somewhat blurred, but this is normal since these are only guidelines in the end.

The next paragraphs explain how we want to achieve the non-technical part of these goals. Discussion is open, though.

#1: Promotion of technology neutrality and interoperability in the field of digital sound processing

We wish to reach the point where we have enough expertise, human and maybe financial resources to offer support to third-party projects and organizations in adopting technology neutral and interoperable solutions for sound processing tasks (not necessairly through the adoption of NASPRO).

This is obviously a long term goal.

#2: Support cooperation among users, developers, distributors and people interested in the project and related external projects

A friendly social network should form around the project in order to enhance relations among these people. Thus, services like mailing lists, forums, fordwarding of contacts can help a lot.

This is a day-by-day commitment and we have already started looking in that direction.

#3: Easy and proper portability to the widest possible number of hardware/software combinations

It is important to say that all components of the architecture have to be developed not only with portability in mind, but also making it possible to adapt them to the conventions of every hardware/software combination to the largest possible extent.

#4: Easy reusability of parts or the whole architecture for any purpose

We feel that giving away the source code is only a prerequisite to allow its understanding, easy integration and reusability in other software.

Apart from proper documentation, the architecture itself has to be designed to allow reusability of each component which can be logically and conveniently isolated from the rest.

#5: Support as many plugin APIs and related features as possible

The title says it all. As explained before, the more support today means the more support tomorrow, and also more fairness in terms of support in respect of each API.

#6: Support the development of new API-independent features

Put it simply, it would be cool and would help developers a lot.

#7: Support the research on new sound processing paradigms

This doesn't mean the creation of new alternative APIs or the corruption of existing ones, but instead the promotion and/or support of new ideas which can enhance the development, performance or use of sound processing components in any way.

When there will be enough resources, we maybe could have a group of people focusing exclusively on this kind of stuff.

#8: Ease of access and use for developers, users and everyone else

Our technology has to be easy to develop with and at the same time easy to work with.

All feedback has to be carefully handled to try to take into account everyone's needs and requests.

#9: High performance and real-time suitability

Performance should never be sacrificed, unless there is a very good reason for it.

Developers should always keep in mind that this software is developed for real-time performance, and that the less the user notices its existance, the better. Also they should remember that it is an infrastructure and not an end product.

#10: High quality and valuability of the code

All the code has to be carefully checked via extensive automated tests, and such tests should be always available at least to the distributors as well (in other words, the source packages should contain them, but it is not required that they get installed).

Contributed code has to be subject to a cycle of tests and reviews as well.

The code should be lean and clean, uniform, documented, should adopt wise algorithms and conform to the coding style conventions explained later on in this document.

#11: Extensive documentation of every part of the architecture

For each part of the architecture there has to be hand written documentation covering its installation, use, development and hacking, as well as auto-generated reference documentation for its API whenever it offers one.

Furthermore we could set up a service to promote, link and/or distribute any kind of unofficial documentation (such as tutorials, benchmarks or thesis) written by people internal or external to the project.

#12: Self promotion and acceptance

The diffusion, acceptance and effectiveness of this framework highly depend on people being correctly informed about it.

We will try to do some correct, informative and respectful advertising in the places meant to be used for this purpose. We will also encourage people to promote and support the project, privately or publicly, on their own behalf (we won't take responsibility for what they might say).