...
Note: This guide describes high-level usage of the Audio Weaver. The code generator of Audio Weaver is able to take the bass tone control and generate code for a “BassTone” class that resides on the target. This process is described in the Developing Custom Modules : Developer's Guide.
Audio Weaver flattens the system behind the scenes while presenting the hierarchical version to the user to manipulate. To see the actual flattened system running on the target, use
...
Note: The function classid_lookup.m can be used to determine if a class name is already in use. Refer to Developing Custom Modules : Developer's Guide for more information.
...
We describe some of the fields which are commonly edited here. Refer to Developing Custom Modules : Developer's Guide for a complete description.
...
More detailed information for add_argument() is in Developing Custom Modules : Developer's Guide.
Pins
The function new_pin_type.m was introduced in Adding I/O Pins and returns a data structure representing a pin. The internal structure of a pin can be seen by examining the pin data structure. At the MATLAB command prompt type:
...
AWE_INFO.docControl – Controls aspects of documentation generation. Refer to Developing Custom Modules : Developer's Guide for more details.
AWE_INFO.inspectorControl – Most fields are used internally by the awe_inspect.m command. One user settable field is:
...
AWE_INFO.buildControl – Refer to Developing Custom Modules : Developer's Guide. Most of the fields are used internally by the build.m command. Two user settable ones are:
...
'Bypassed' – the module's inputs are copied directly to its outputs. The generic version copies the ith input pin to the ith output pin. A module may also define a custom bypass function if the generic version is not appropriate. Refer to Developing Custom Modules : Developer's Guide for further details about custom bypass functions.
...
The function returns an integer STATUS that is interpreted as:
Integer | Status |
|---|---|
-1 | There is a wiring error. |
0 | There are no wiring errors, but the wiring is not complete. There are 1 or more pins in the subsystem that are not connected. |
1 | There are no wiring errors and the wiring is complete. The system is ready to build. |
Connections within a subsystem are made by the connect.m command. Each connection is from a named source module / output pin to a named destination module / input pin. The connection.m function catches several different wiring errors:
...
A toolbar on the figure window allows you to adjust the display:
Button | Function |
|---|---|
 | Zoom in |
 | Zoom out |
 | Scroll the display |
 | Display wire information (toggle) |
 | Display module variables (toggle) |
 | Display pin names (toggle) |
 | Refresh the drawing |
All of the tools labeled "toggle" are global and apply to subsequent drawings. The state of the toggle buttons is stored in the global variable:
...
Some modules may utilize the same wire for both input and output. This "straight across" wire buffer allocation is specified within the module's constructor function. Further details are found in Developing Custom Modules : Developer's Guide (No modules in the limiter_example.m have straight across wiring).
...
When subsystems are drawn using the draw.m command, the modules are color coded according to their status:
 |
|
 | Muted = White |
 | Bypassed = Yellow |
 | Inactive = Red |
If you make a change to the module status using either an inspector or programmatically from MATLAB using the awe_setstatus.m command, then the drawing in a figure window will not be automatically updated. Instead, you need to manually refresh the window using the toolbar button or right-clicking on an empty part of the figure window and selecting Redraw.
...
The real power of this function comes from its ability to support wild cards. Use the string '*' to specify any module or pin. For example, consider the Limiter Example Figure Drawing.
To determine what modules are connected to the output of the "scale" module, use:
...
As an example, refer back to the system created by the script limiter_example.m shown in the Limiter Example Figure Drawing. Let's locate the input pin "in" on the "lim" module. This is the destination of a connection:
...
As an example, refer back to system created by the script limiter_example.m shown in the Limiter Example Figure Drawing. To locate the output pin "out" of the module "scale" use
...
For example, consider the limiter_example.m shown in Limiter Example Figure Drawing. The agc_multiplier module has two input pins as shown below:
...
As an example, consider the subsystem created by the test script limiter_example shown in the Limiter Example Figure Drawing. The system shown is the one prior to flattening. The actual system running on the target is
...
The top line of blue blocks indicates when 32-sample audio processing is active. This happens at regular intervals and since this is the smallest block processing (and thus the highest priority), the 32-sample processing always runs to completion. The blocks are sequentially numbered from 0 to 7. The second line of yellow blocks indicates when the 128 sample block processing is active. Block 0 of the 128-sample processing actually starts at the same time as block 0 of the 32-sample processing. However, since the 32-sample block processing is higher priority, the 128-sample thread pends is suspended until the 32-sample processing is complete. Once the 32-sample processing is done, the 128-sample processing begins. Block 0 of the 128-sample processing takes some time to complete and during this time it is interrupted by the high priority 32-sample block processing. That is why block 0 of the 128-sample processing is divided into 3 different segments. Block 0 of the 128-sample processing completes and this leaves some unused processing shown in blue. The entire process repeats every 128 samples.
...
There are certain assumptions built into the helow figure below. First, the example assumes that all of the 128 sample block processing completes before the second block of 32-samples is processed. This is not a hard requirement since large block processing is only useful if the processing can extend over multiple smaller 32-sample blocks.
...
The inspector panel shown in the combined inspector panel consists of 4 separate "sub-inspectors", one for each internal module. By default, Audio Weaver draws sub-inspectors and individual controls from left to right. Subsequent controls are added to the right of the last control.
...
If the variable is an array, then controlType='grid' and the following is drawn:
If the variable has usage 'const', then controlType='const' and the variable is drawn as a read-only edit box
If the variable has no range information, then controlType='edit' and it is drawn as an edit box:
If the variable has usage 'parameter', has type 'int', and there are only two items, then controlType='checkBox'
If the variable has usage 'parameter', has type 'int', and there are three to nine items, then controlType='dropList'. For each allowable integer value, you can specify a string to provide an easy-to-read drop list.
If the variable has usage 'parameter', has type 'int', and there are 10 or more items, then controlType='knob'. Or, if the variable has usage 'parameter' and type 'float', then controlType='knob'.
If the variable has usage 'state', has type 'int' and has exactly two items, then controlType='LED'.
If the variable has usage 'state', has type 'int' and has three or more items, then controlType='meter'. Or, if the variable has usage 'state' and type 'float', controlType='meter'.
Otherwise, a default controlType cannot be assigned to this variable.
The default .controlType string can be overridden. For example, the agc_core_module.m uses a knob for the recoveryRate control. You can change this to a slider using the command:
...
where FILENAME is a string specifying the file to add along with absolute or relative file path and ATTRIB is the 8-bit attribute byte discussed as below.
Attribute Byte | Description |
|---|---|
24 | Compiled Script file (non-bootable) |
26 | Compiled Script file (bootable) |
40 | Compiled Preset File (non-bootable) |
42 | Compiled Preset File (bootable) |
FILENAME must be at most 24 characters in length, for example “agc_example.awb”; this is checked by the function. The function also checks that FILENAME does not already exist in the Flash File System.
...