This page walks through a complete example of an audio module, starting from the high-level MATLAB model and continuing through the generated code. This example is identical to the scaler_smoothed_module.m contained in the Deprecated module library. We go through this module in a systematic fashion and reference the source files listed in Scaler Smoothed Example Source Files. (8.D.2.2 ) Examples Module Library contains additional module examples which highlight advanced features.

This module example is part of a larger audio module DLL containing several example modules. The base directory for the audio module examples is <AWE>\AWEModules\Source\Examples\where <AWE> refers to the root directory of the Audio Weaver Designer installation.

The directory contains several subdirectories. This directory structure must be followed when creating other custom audio module libraries. In order to build the examples modules, the above path must be on the Audio Weaver module path variable, which can be retrieved in MATLAB with the ‘add_module_path’ command. The correct path should already be included in a normal installation of Designer, but if it is not, or if another path needs to be added, the module path can be updated using the ‘add_module_path’ command or with the File > Set Module Path menu in Designer.

Module M-files

Each audio module has an associated module M-file, item 1 shown in Figure 1. For this example, the file is found in

<AWE>\AWEModules\Source\Examples\matlab\scaler_smoothed_example_module.m

and a listing is shown in scaler_smoothed_example_module.m. When you first initialize Audio Weaver using awe_init.m, this file will be placed on your MATLAB path. The module m-file completely describes the audio module to MATLAB. It contains:

• Input and output pins descriptions:
  Data types, number of channels, block sizes, sample rates, etc.

• Instance structure variables:
  Date types, variable names, array sizes, memory allocation rules.

• Documentation:
  Descriptions of variables, pins, and text describing the overall audio model.

• MATLAB implementation of the module:
  Processing function (optional), and if needed, set function, bypass function, and get function. There may also be a prebuild function which is called when a system is built.

• User interface:
  Individual variables are exposed and tied to controls. Controls are positioned and configured.

• Browser information:
  This is the information for AWE Designer window to list under specific folder, search tag, bit map image of the module in Designer window etc.

All of these items above are documented in the Audio Weaver Matlab API. The specific items in the module m-file pertaining to module generation are variables, code markers, and wiring allocation guidelines described in (8.D.2.2 ) Generating Module Libraries (in particular, the sections Specifying Wiring Constraints and Code Markers and Template Substitution).

Subsystems are very similar to modules, but also contain a list of internal modules and a list of connections between modules.

Audio Module Instance Structure

Every audio module has an associated instance data structure that holds the variables – state and parameters – needed by the module. In this example, there are 4 variables described in the module m-file:

The type definition for the instance data structure is contained in the file ModScalerSmoothedExample.h and is automatically generated by Audio Weaver:

The instance structure begins with a common substructure of type ModuleInstanceDescriptor. This substructure points to the module's input and output wires, points to the real-time function currently used by the module (Processing, Bypassed, Muted, etc.), and points to the class instance structure.

The module header is followed by the instance variables described in the MATLAB file. There is a one-to-one correspondence between the variables shown in the instance structure and those added by MATLAB. The description of each variable is used as a comment.

The header file also contains a few other items. First, there is a bit mask for each variable in the data structure. The mask corresponds to the position of the variable within the instance structure. Note that the module header is 8 words long and thus the first bit starts in the 9th bit position. These bit masks can be used by the _Set() and _Get() functions to determine which variable within the instance structure has been modified.

The header file also defines an offset for each instance variable. Again, this is the offset from the start of the data structure, in 32-bit words. These offsets are provided to help implement system control using a host interface.

There is a unique class ID.

#define CLASSID_SCALERSMOOTHEDEXAMPLE (CLASS_ID_MODBASE + 32768)

This integer uniquely defines the module class to the Server. Next is the definition of the module's constructor function. In this case, since the module does not have any arrays, the generic module constructor ClassModule_Constructor is used.

And finally, there are definitions for the processing and set functions:

void awe_modScalerSmoothedExampleProcess(void *pInstance);

UINT awe_modScalerSmoothedExampleSet(void *pInstance, UINT mask);

Audio Module Source Code (.c and .h files)

Each audio module has a set of associated functions. These functions, and their definitions, are placed in .c and .h files, respectively. At a minimum, every audio module requires a processing function. In addition, a module may specify several optional functions:

• Constructor() – Performs additional memory allocation or initialization when a module is instantiated. If a module has an indirect array, such as an FIR filter, then a constructor function is required. In many cases, MATLAB can generate the constructor function automatically.

• Set() – Implements a module's control functions which translate high-level interface variables to low-level variables. The Set() function is automatically called whenever an internal variable of a module is written by the Server during tuning.

• Get() – Implements a module's control functions which translate low-level variables to high-level interface variables. The Get() function is automatically called by the Server whenever an internal variable of a module is read during tuning. Very few modules actually implement this function.

• Bypass() – Implements custom bypass functionality. Required when one of the standard bypass functions is not suitable.

The module .c source file also contains a single class structure that describes the module to the Audio Weaver run-time and dynamic memory allocation functions. For example, this module contains the class structure:

The class structure contains pointers to the 5 functions listed above. The constructor function is NULL indicating that the module requires no memory outside of its instance structure and that the generic constructor should be used instead.

The #ifdef BUILD64 section is required internally by Designer to correctly access the module’s variables in 64-bit architectures.

The class ID, CLASSID_SCALERSMOOTHEDEXAMPLE which is defined above, is a unique integer identifying the module to the Server. When instantiating a module of this class, the Server is told to instantiate a module of class "ModuleScalerSmoothedExample". This string identifier is then translated to the underlying class ID through the module DLL shown as item 9 in Figure 1. Ensuring that each audio module has a unique classID can be tedious. To facilitate this process, each module library has a text file named classids.csv, shown as item 3 in Figure 1, containing a comma separated list of audio modules and their class IDs. A portion of the file is shown below:

The classID for the ScalerSmoothedExample module equals the IDOFFSET (32768) plus the value listed next to its class name below (0). Class IDs starting with 32768 are reserved for custom audio modules.

Audio Module Schema File

The generated schema file ExamplesSchema.sch provides a "blueprint" of all of the available objects on the target processor to the Server. This enables the Audio Weaver Server to instantiate and manipulate objects by name rather than hexadecimal IDs or offsets. The schema file for each module pack is embedded in the module DLL and is shown as item 9 in Figure 1. It contains definitions for all of the available audio modules in the module pack.

The entire schema file for the example module library is shown in ExamplesSchema.sch. The portion corresponding to the ScalerSmoothedExample module is shown below.

Note the one-to-one correspondence between the schema description and the C type definition shown above. Furthermore, the C substructure ModuleInstanceDescriptor maps to the BaseModule descriptor in the schema file.

To create an instance of a smoothly varying scaler on the target, the Server is told "create an instance of class ModuleScalerSmoothedExample and call it Scale1". The Server converts this to the command "create an instance of object 0xBEEF8800" via the schema file. The hexadecimal value 0xBEEF0C16 corresponds to the unique class ID CLASS_ID_MODBASE + 32768contained in the class structure.

On the target, the array of module class objects is traversed looking for class ID 0xBEEF8800. Once the class object is found, the corresponding constructor function, stored as a pointer in the class structure, is used to allocate one instance of the object. The address of the newly instantiated object is returned to the Server, and the Server associates the object's address with the name "Scale1". The Server maintains this mapping between symbol names and actual memory addresses.

The schema file also lists the module's instance variables and is used to compute offsets from the start of an object. When the value "Scale1.gain" is set during tuning, the Server translates this to a specific address on the DSP (PC) using the "Scale1" object address as a base, and then adding an appropriate offset. In this case, the offset equals 8, the size of BaseModule.

Generating Module Code

The MATLAB file scaler_smoothed_example_module.m has a complete description of the audio module with sufficient information to generate all of the source files and documentation. You can generate the source files for a smoothly varying scaler using the commands:

will be created in MATLAB's current working directory. Specify the directories for code generation with the second argument:

The following files will be created in the directories specified by DIR:

• Include/ModScalerSmoothedExample.h

• Source/ModScalerSmoothedExample.c

You can also specify that the C code should be formatted using the ident.exe utility (supplied) via a third argument:

Modules are usually not created in isolation, but are part of a particular module pack library. Modules need to be created as a unified library so that the combined schema file ExamplesSchema.sch can be written. The MATLAB script make_examples.m generates code for the entire Examples module library. The script first creates a cell array of audio modules:

Important point to be noted here is that the module must be added to cell array with all the arguments required. This is mandatory for new AWE Designer.

Some other example audio modules are subsystems that utilize modules found in other libraries. We indicate this dependency relationship using the lines

Then call a function to generate the source code for the overall library:

Code for each module in a module pack is separately generated followed by the combined schema file. The third argument, 'Examples', specifies the module pack name and the forth argument specifies the dependencies on other module packs. The fifth argument, GENDOC, controls whether documentation in HTML format should be generated.

When you run the MATLAB script ‘make_examples’ the MATLAB output window will show an output similar to the following:

You'll note that all source files are marked as "Unchanged". Audio Weaver only overwrites generated files if there has been an actual change. This minimizes file changes and makes it easier to work with source code control systems.

Template Substitution

Audio Weaver uses template substitution to generate audio module source and header files. The template files are shown as item 2 in (8.D.2.2 ) Module Development Overview | OverallEnvironment and two files are used:

• <AWE>\matlab\module_generation\templates\awe_module_template.c

• <AWE>\matlab\module_generation\templates\awe_module_template.h

The template files contain boiler plate text together with string substitution variables and special preprocessor directives. Consider a portion of the file awe_module_template.h:

Each substitution point is shown as $NAME$ in the template file. These substitution points are replaced with the code markers added via awe_addcodemarker.m commands in the module file. For example, when generating the scaler_smoothed_example_module, the string variable $description$ is replaced by "Linear multichannel smoothly varying scaler" and $classNameUpperCase$ is replaced by "ScalerSmoothedExample" to yield:

The template files also contain special forms of preprocessor directives – independent of the standard C preprocessor directives. Further down in awe_module_template.h, you'll find the function declarations:

The symbols ## identify a preprocessor directive reserved for the code generator. The directives are evaluated during code generation based on the values of the variables, for example the value of $useCustomSetFunction$ determines if code will be eliminated or exist in the generated file. The scaler smoothed example module has:

• $useCustomSetFunction$ defined as 1

• $useCustomGetFunction$ defined as 0

• $useCustomBypassFunction$ defined as 0. 

This yields the generated header code:

The variables used during template substitution are referred to as "code markers". Many code markers are generated automatically by the awe_generate_module.m function. Some code markers are explicitly defined in scaler_smoothed_example_module.m.

Code markers beginning with the string "Insert:" cause input to be read from a specified file. For example, the processing function template in awe_module_template.c is:

The string $processFunction$ is taken from the file Inner\InnerScalerSmoothedExample_Process.c

shown in InnerScalerSmoothedExample_Process.c. You'll note that this is bare code missing even the function definition (which is in the template file). The other code markers – "preProcessFunction" and "postProcessFunction" are not defined. After template substitution, we end up with the final processing function ModScalerSmoothedExample.c shown in ModScalerSmoothedExample.c.

Building the Audio Module DLL

At this point, the source code for all of the modules in the Examples library has been generated. Open up and rebuild the Visual Studio solution file <AWE>\AWEModules\Source\Examples\Examples.sln.

with the build configuration set to x86 Release. The solution builds the DLL and then copies it into the directory <AWE>\Bin\win32-vc142-rel so that it can be referenced by the Server. Further details on this step can be found in (8.D.2.2 ) Building Audio Module DLLs | BuildingExamplesDLL.dll.

Summary of Steps Involved in Writing an Audio Module

To summarize, the steps required in writing a new audio module are:

1. Create the MATLAB module m-file described in Module M-files. It defines:

   1. Input and output pins

   2. Instance structure variables

   3. Links to inner C code.

   4. Documentation

   5. User interface

   6. Module browser for AWE Designer

2. Write the inner C code for the processing function.

3. Write the inner C code for the other module functions, Constructor(), Set(), Get(), and Bypass(), if needed.

4. Pick a unique integer ID (any number in the range 32768 to 63487) for the new module class ID. Add this information to the file classids.csv associated with the module library.

5. Add the module function to the specific module pack library generation script, for example make_examples.m. Run the script file to generate the source code and create the schema file.

6. Add the generated .c and .h files to the project for building the audio module pack library (e.g., ExamplesLib.vcproj) and build the library.

7. Build the audio module DLL so that the new modules are visible by the Server.

Scaler Smoothed Example Source Files

The following sections feature expandable code blocks with the contents of example source files.

scaler_smoothed_example_module.m

InnerScalerSmoothedExample_Process.c

InnerScalerSmoothedExample_Set.c

ModScalerSmoothedExample.h

ModScalerSmoothedExample.c

classids.csv

ExamplesSchema.sch

ExamplesSchema.cpp

Examples.h