Three Levels - Audio Weaver Tips (Issue #002)

 
 
We asked Audio Weaver users of three different skill levels to each give us a favorite tip for using Designer.  Ready to Level-Up?
 
 
 

Level 1 - Rookie

Tip: You can edit the input pin, but not the output pin.

I didn’t notice it at first, but Audio Weaver modules actually adapt to handle whatever’s on the input wire - they ‘just work’, regardless of the number of channels or samples per block (“block-size”).  To do this, Audio Weaver uses “wire propagation”, where the audio properties ‘flow’ down-stream through the block-diagram - ultimately propagating all the way to the output pin. (So, if you want to change the number of output channels, you do that upstream of the output pin with things like Routers and Mixers.)

 
 

Level 2 - Enthusiast

Tip: Process your laptop’s line-in using Designer’s built in “Native Target”

As you know, Designer generates audio-processing models that run on the AWE Core - the runtime engine that gets integrated into the firmware of an embedded target. To allow designs to run in real-time on our Laptops, AWE Server includes a “Native Target” with AWE Core for x86/x64 CPUs.  The Native Target basically just has the plumbing to feed the AWE Core with audio from files and/or Windows audio devices. 

Each Layout (.AWD) has a property where it can specify which input source to use when running on the Native Target. (This is handy if you want to create a demo block-diagram that processes a specific audio recording.) By default, new .AWDs use a Bach piano .MP3, but you can change it to use a Windows audio device for real-time input! 

(Note: to tell the Native Target which Windows audio-devices to plug into AWE Core, Go to AWE Server’s File/Preferences menu.)

 


Level 3: Power User

Tip: Create a strip chart of state or events over time

When designing, tuning, and/or debugging, it’s often useful to be able to see a “trace” of what’s happened over time. Maybe you want to visually see how often your microphone processing detects voice or how often your limiter/compressor are kicking in as you tune other parameters in the processing pipeline. In this example, I just want to see when the RMS level of my input is greater than some tunable threshold - which is a little hard to see when just looking at the ‘current’ output of the comparator.

 
 
 
 
Have a question about one of these tips? Have a tip / technique of your own we might feature? Share below!