I brought this up in a thread on another topic. I'm using a _lot_ of DC sources in my current project. Many of them, around half, are the equivalent of 'code constants'. In cases like these, an option to select an 'unchangeable' DC source would tell the compiler to generated a code constant instead of allocating data buffers. The user would not be able to change the value of an 'unchangeable' DC source from it's inspector when running. This should result in more efficient code.
Is something like this already available?
One important thing to understand about the AWE Core is that there is no code-generation happening. There are only 'Modules' and 'wire buffers', and the arrangement and order of these is created dynamically as tuning commands are sent to the AWE Core. As modules are added to a Layout, the AWE Core's memory management system will calculate and dynamically allocate the fewest number of buffers possible.
If for example, you have three modules (In->A->B->C->Out), and each can process in-place, then this whole layout can be fulfilled with a single wire-buffer. So, while one may have 200+ wires in your graphical design, the AWE Core may be able to execute that Layout using just a hand-full of physical buffers (depending on the requirements and context of each module).
Additionally, each wire buffer only holds one 'block' of data, and for control wires, the block size is (1). So DC source modules take very little data; it's just the module-instance's state data plus the single-word wire-buffer.
One thing you might consider is using a "Source" module (not "DC Source"), which has a multichannel output; conceptually, it's an like an array. Down-stream, one can use a router module or paramset module to pluck the right channel out of the multichannel "control bus".
Thanks Matt, I appreciate the answer and the helpful background about the AWE core. Does 'custom' code get generated for the actual target DSP or is it some kind of AWE core configuration that gets loaded to the target DSP?
The fact that a DC source only represents a single word of data allocation puts the issue to rest for me. I like your idea of using a multichannel source module. When the time is right, I'll give it a try.
Well this is an FAQ if I've ever seen one :) The AWE Core Integration Guide covers this in detail, but here's the overview:
In a typical "embedded" audio system, there's some custom firmware (mostly C-code) that sets up the IC's peripherals, the initializes the converters, configures the DMAs, etc; once this is debugged, you can do a very simple, raw audio pass-thru/loopback from RX to TX (i.e. the equivalent of 'hello world' in the embedded-audio world.) Into this 'pass-through' system, you plug-in the AWE Core, feeding RX audio in, and pulling freshly processed audio out and copying it to the TX buffers. (You also add a little 'plumbing' code to get the tuning commands, and control-knob data over into the AWE Core.)