About This Application Note

The Bringing Algorithms into Audio Weaver Application Note describes different approaches to adding new processing algorithms to Audio Weaver.

Modules

In Audio Weaver, a module is a fundamental software object that performs a specific algorithmic process, and a wire is a fundamental software object that transfers data between modules. Signal processing layouts are constructed in AWE Designer by placing module blocks on the canvas and connecting their inputs and outputs with wires. Important module tuning parameters can be controlled in real-time using a module’s inspector window. The AWE Designer Pro Edition and Module Creator licenses enable users to create new modules which call upon their preferred processing algorithm source code or compiled libraries.

When creating a new module, a particular collection of files needs to be stored in a root directory called a module pack. Files in a module pack contain a module’s algorithm functions, detailed usage information, visual components, and supported methods for user interaction and control. Files for multiple modules can reside in the same module pack. A module pack also contains a MATLAB script file and a Visual Studio solution file to help automate the module creation process.

Running the Module Pack Creator Wizard tool in AWE Designer generates a new module pack containing files for one module. The module’s inner C files are used to implement the module’s real-time processing function and any additional functions related to the algorithm, such as memory allocation or parameter control. The module’s MATLAB function file is used to create a distinct module class; reference functions implemented in the module’s inner C files; define the module class’s parameters, inspector, and input and output data constraints; and specify additional features to enhance the module’s usability in AWE Designer, such as help documentation or whether the module can be added to AWE Designer Standard Edition. For a module pack to contain multiple modules, each module needs its own inner C and MATLAB function files. Additionally, the module pack’s CSV file needs to include each module’s name and its corresponding unique class ID, and the MATLAB script needs to instantiate a default instance of each module class.

Running a module pack’s MATLAB script generates additional files which are used by the Visual Studio solution to build a DLL file. Once a module pack’s DLL file resides in the same directory as the AWE Server executable file and the location of the module pack is specified in AWE Designer, the modules in the module pack can be accessed and used in AWE Designer on the PC. To additionally deploy new modules to an embedded processor, users can write their own programs to compile the files generated by the module pack’s MATLAB script into a static library file for their target processor and link that library file into the target’s AWE Core application.

For more details on creating custom modules, please refer to Creating Custom Modules and MATLAB Scripting API. To reference module pack source code, please see Examples Module Library and the local files contained in the following directory:

Subsystems

A subsystem encapsulates a collection of modules and wires inside a single block without affecting the overall layout’s processing performance or resource requirements. Implementing an algorithm inside a subsystem using modules developed by DSP Concepts allows Audio Weaver users to take advantage of DSP Concepts’ processor-optimized code while maintaining visual organization of their overall layout’s distinct sections.

Users can design a subsystem to include multiple inputs and outputs for transferring audio and control data between the subsystem and the external layout. A subsystem can also include a custom user-designed inspector created in AWE Designer for external display and operational control of selected internal module parameters.

By default, users can navigate into a subsystem to configure the internal layout and interact directly with the interior modules. Opting to create a navigation password for a subsystem helps to limit the ability to look inside it, although it is very easy to bypass this navigation password and access a subsystem’s complete implementation details in a human-readable format by saving a layout with the subsystem in it as a JSON file.

When it is time for a layout to start processing data, AWE Server receives human-readable commands from MATLAB corresponding to the layout drawn in AWE Designer. Each module in the layout, including any module inside a subsystem, is instantiated one at a time using its distinct module class name. As a result, the time it takes to instantiate a subsystem is directly proportional to the number of modules inside of it.

For more details on subsystems and user inspectors, please refer to Subsystems.

Compiled Subsystems

A compiled subsystem is a subsystem that has been turned into a new module class. Like a regular module, it takes substantially less time to instantiate a compiled subsystem than a regular subsystem since only a single module class name is communicated to AWE Server for a compiled subsystem. The modules inside a compiled subsystem and their respective parameters cannot be directly viewed or accessed by users.

Like a new module, creating a compiled subsystem requires a module pack. A compiled subsystem’s module pack does not use inner C files and instead relies on the algorithm functions which are already implemented for the modules used in the subsystem’s layout. Instead of handwriting the entire contents of a compiled subsystem’s MATLAB function file, a single MATLAB function can generate much of this file based on the implemented subsystem’s layout. Minor edits to this generated MATLAB function file are required to specify that the subsystem’s layout will be compiled into a new module class, and additional edits can be made to further define the compiled subsystem’s module class. The compiled subsystem’s MATLAB script needs to call the MATLAB scripts of all module packs which contain modules used in the compiled subsystem’s layout, and all locations of those module packs need to be added to the compiled subsystem’s Visual Studio solution linker.

For more details on compiled subsystems, please refer to the Compiled Subsystems Application Note.

Reusable Subsystems

A Reusable Subsystem is a subsystem that has been saved for ease of reuse across any layout. Whereas reusing a regular subsystem requires copying it from one layout and pasting it to a new destination, Reusable Subsystems appear in the AWE Designer module browser alongside regular modules. The process of converting a regular subsystem to a Reusable Subsystem is accomplished in AWE Designer and requires minimal user configuration and no coding.

Unlike a regular subsystem, a Reusable Subsystem appears as an ordinary module block which cannot be navigated into and must be configured through its inputs and its user inspector. A Reusable Subsystem maintains the same user inspector during reuse.

A Reusable Subsystem is represented by JSON and XML files which are automatically generated and placed in a user-specified root directory when the Reusable Subsystem is created. Any user with a local copy of the root directory can add a Reusable Subsystem to their layout once they specify the location of the root directory in AWE Designer, and any user can easily modify its internal contents by editing its JSON file or reverting it back to a regular subsystem in AWE Designer.

For more details on Reusable Subsystems, please refer to Subsystems | Reusable Subsystems.

Compiled Reusable Subsystems

A Compiled Reusable Subsystem is a Reusable Subsystem that is represented by an encrypted AWB file. Any controllable module variables within a Compiled Reusable Subsystem are represented in a supplementary META file. Any user with a local copy of the Compiled Reusable Subsystem’s root directory can add a Compiled Reusable Subsystem to their layout once they specify the location of the root directory in AWE Designer.

The modules inside a Compiled Reusable Subsystem and their respective parameters cannot be directly viewed or accessed, and a Compiled Reusable Subsystem cannot be reverted to a regular subsystem. A layout containing a Compiled Reusable Subsystem requires substantially less time to instantiate than a layout with a regular subsystem or Reusable Subsystem, although a Compiled Reusable Subsystem requires additional memory and slightly more processing time.

For more details on Compiled Reusable Subsystems, please refer to Subsystems | CompiledReusableSubsystems.

Summary of Approaches