flatmax@592: flatmax@592: flatmax@592: flatmax@592: flatmax@592: flatmax@592: CARFAC C++: CARFAC C++ flatmax@592: flatmax@592: flatmax@592: flatmax@592: flatmax@592: flatmax@592: flatmax@592: flatmax@592: flatmax@592: flatmax@592: flatmax@592: flatmax@592: flatmax@592: flatmax@592: flatmax@592:
flatmax@592: flatmax@592: flatmax@592:
flatmax@592: flatmax@592: flatmax@592: flatmax@592: flatmax@592: flatmax@592: flatmax@592: flatmax@592: flatmax@592: flatmax@592: flatmax@592: flatmax@592: flatmax@592: flatmax@592:
flatmax@592:
CARFAC C++ flatmax@592: flatmax@592:
flatmax@592:
C++ implementation of CARFAC
flatmax@592:
flatmax@592:
flatmax@592: flatmax@592: flatmax@592: flatmax@592: flatmax@592:
flatmax@592:
flatmax@592: flatmax@592:
flatmax@592:
flatmax@592:
flatmax@592: flatmax@592:
flatmax@592:
flatmax@592:
flatmax@592:
CARFAC C++
flatmax@592:
flatmax@592:
flatmax@592:
Author:
{Matt Flax <flatmax@>}
flatmax@592:
Date:
2013.02.08
flatmax@592:

flatmax@592: Introduction

flatmax@592:

This C++ code implements Dick Lyon's CARFAC model for the peripheral hearing circuit.

flatmax@592:

flatmax@592: Philosophy of the implementation

flatmax@592:

flatmax@592: Matching the design document

flatmax@592:

As requested by the CARFAC design description, this codebase uses Eigen to compute matrix/vector operations.

flatmax@592:

flatmax@592: Object oriented acritecture

flatmax@592:

Where possible common paradigms inherit from common Objects. This aims to minimise the amount of coding required to implement and modify CARFAC. For example, the EarComponent encapsulates the CAR, AGC and IHC where all of the have the common features of Coefficients, Parameters and State.

flatmax@592:

flatmax@592: Common code

flatmax@592:

Where possible typedefs, definitions, includes and namespace inclusions which are common to the code, or usefull outside of class definitions are put in the CARFACCommon.H file.

flatmax@592:

flatmax@592: File naming convention and header guards

flatmax@592:

C++ files in this codebase are named using the .C and .H suffixes (C code uses .c and .h).

flatmax@592:

Header guards are labeled using the files name with '_' characters, for example.H would become EXAMPLE_H_.

flatmax@592:

flatmax@592: Global variables

flatmax@592:

In general the use of global variables is discouraged. Where possible the code must be instantiated many times on the same computer system and the use of global variables complicates having multiple instances of shared library classes.

flatmax@592:

flatmax@592: Class and variable naming convention

flatmax@592:

In general, classes begin with capitol letters and a variable name begis with a lower case character. The consider a class for example :

flatmax@592:
    class ForExample { class def here };
flatmax@592: 
flatmax@592:     ForExample forExample;
flatmax@592: 
flatmax@592:     class OMG { class def here };
flatmax@592: 
flatmax@592:     OMG omg; // here it is clear what is the type and what is the variable.
flatmax@592: 

The class 'ForExample' is defined, and the variable name 'forExample' may be used in the code, which clearly indicates the type of the variable.

flatmax@592:

The concept of labeling variables using 'p' for pointer, and type name references is not necessary, and in some cases discouraged. Consider for example,

flatmax@592:
 float *fs 
flatmax@592: 

defining the pointer to the sample rate. If we were to use

flatmax@592:
 float * pFFs // don't do this - difficult to see that pFFs references fs - the sample rate 
flatmax@592: 

, it becomes rather difficult to understand that pFFs actualy points to the sample rate.

flatmax@592:

A deeper argument for using simple variable names (in C++) is as follows. Good engineers program classes and methods which are short and concise. As monitors (LCDs) get larger, most of your methods and in some cases classes are visible in one or two pages of your monitor. Consequently if the exact type of a variable named 'fs' needs to be found, it is as simple as looking at the top of your monitor or scrolling up a little to find a method's input variable name/type. In the case of class member variables, a class 'SoundCard' is expected to define a sound card. Consequently certain member variables are expected to exist, for example, fs, inputChannels, outputChannels and so on. If the actual types of these variables have been forgotten, then the header file is referenced, and this is normally as simple as a few key strokes to change from the SoundCard.C file to the SoundCard.H file to inspect the names and types of available member variables.

flatmax@592: flatmax@592:
flatmax@592: flatmax@592:
flatmax@592:  All Classes Files Functions Variables Typedefs Defines
flatmax@592: flatmax@592: flatmax@592:
flatmax@592: flatmax@592:
flatmax@592: flatmax@592:
flatmax@592: flatmax@592: flatmax@592: flatmax@592: flatmax@592: