view doc/dox-mainpage.dox @ 33:f8fe1aadf097

-Modified AIMCopy for slices experiment
-Added gen_features script to just generate features for a given SNR

/*!
\mainpage AIM-C developer documentation

\section intro_sec Introduction
AIM-C is a real-time version of the the auditory image model (AIM)
developed at the <a href="http://www.pdn.cam.ac.uk/groups/cnbh/">
Centre for the Neural Basis of Hearing</a>.

The main development site for AIM-C is at http://aimc.acousticscale.org/. The 
code is available at http://code.google.com/p/aimc/.

\section design_sec Design
AIM-C uses a block-based processing scheme. A mono input signal is
split into short segments, which are sequentially 'pushed' through the
processing pipeline. The pipeline consists of a number of modules in a
tree structure.

The basic unit of data in AIM-C is the signal bank, and the basic
processing unit is the module. A signal bank represents a short
segment, or 'frame', of an audio signal with multiple
channels. Modules generally take a frame (represented as a signal
bank) as input, and generate zero, one, or more signal bank frames as
output. Each module maintains a list of 'target' modules, to which
it 'pushes' the frames that it generates. Each module
performs processing on the output of the previous module, and in turn,
push the output that they produce to their targets.

This feed-forward, tree-like system allows modules to generate as many output
frames as necessary for each input frame. It also allows for easy 'rewiring'
of chains of modules. For example, a 'viewer' module could be temporarily 
added as a target of another module while the user was interested in seeing
that module's output.

Since each module is an instance of a class, it can retain the necessary state
variables within the class between calls.

\section style_sec Coding style

For the most part, AIM-C now follows the <a
href="http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml">
Google C++ style guide</a>. The original (2006-2009) AIM-C codebase
used a different style, and so you may find some files which still
follow the older conventions. New code should adhere to the Google style
guide.


*/