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.

...

For more details on creating custom modules, please refer to the Audio-Weaver--Module-Developers-Guide.pdfand the Audio-Weaver--Matlab-API.pdf located in C:\DSP Concepts\<AudioWeaver>\Docs. For Creating Custom Modules and MATLAB Scripting API. To reference module pack source code, please refer to see The Examples Module Library and the local files contained in the following directory:

C:\DSP Concepts\<AudioWeaver>\AWEModules\Source\Examples.

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.

...

For more details on subsystems and user inspectors, please refer to the Audio-Weaver-Designer--Users-Guide.pdf located in C:\DSP Concepts\<AudioWeaver>\Docs 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

...

https://dspconcepts.atlassian.net/wiki/spaces/DOCHUB/pages/2748810681/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

...

https://dspconcepts.atlassian.net/wiki/spaces/DOCHUB/pages/2748810681/Subsystems#CompiledReusableSubsystems.

Summary of Approaches

Table 1

...

: Summary of Approaches to Adding New Processing Algorithms to Audio Weaver

...