13 Aug
2003
13 Aug
'03
11:55 p.m.
On Wednesday 13 August 2003 06:40 pm, Brad Arant wrote:
Would like to respond to Pete Yadlowsky...
Thanks, Brad.
|- I've done away with the distinction between
control signals and audio
|signals.
Early on I adopted this approach but have changed my
ways as I traveled down
the
path for a few reasons. Actually, I have made the distinction of a control
signal
versus an audio path for the sake of patching. A control signal in my system
is
primarily a single channel signal but has all the characteristics of a
single
audio channel. The audio channel is actually a stereo 2x channel.
I can see that if the system has a built-in stereophonic sense that you'd want
control and audio signals on separate "busses". However, in the system I've
been working on (I'm calling it XAK: extensible audio kit) there's no innate
support for any particular number of channels. I wanted the flexibility to do
stereo, quad, septaphonic, etc, so I deliberately omitted any assumed sense
of channel-ness. So, how to handle an arbitrary number of channels? There is
support in place such that XAK's plugins can be written to allow for blocks
of arbitrary numbers of input or output ports, designated during a
post-initialization configuration phase. To configure, say, an N-output
reverb unit:
self->outs = xak_output_bank (self, "out");
Which produces a block of output ports named out1, out2, etc. (This brings me
to another salient feature: ports are identified by symbolic names, rather
than numbers, granted at init/configuration time.) By this feature, one can
patch together an N-channel audio buss of virtually any width.
I would also like to say that I have looked at the
Jack and LADSPA signal
paths
and I believe they are single precision floating point numbers. I personally
have adopted the double precision format
As have I.
and have done extensive benchmark tests and
have found no degradation in performance
Yes. I believe double-precision is the standard data type used by most
floating-pt processors. Single-precision floats must first be converted to
doubles at each computation, thus actually degrading performance slightly.
I would like to comment on this as well. The audio and
signal path objects
that
I have described actually have the number of samples contained within a
packet object and these are passed between the objects.
The packet idea is interesting. I'll consider it further.
|- Every input port is a mixer/modulator.
Internally though, I create a separate module that is
"auto-patched"
into the patch for two reasons; 1) I dont incur the overhead of a summation
or modulation process if there aren't two signals to contend with
With XAK's "multi-jacked" input port, the signal sum/product is initialized
with the value of the first feeder signal. If there are additional signals to
deal with, only then is the necessary arithmetic performed.
and 2) I do
not burden the module code writer with the additional task of dealing with
the process of summation or modulation of multiple inputs.
XAK handles this for the coder transparently by a certain function provided
with a set of core utilities:
sample = xak_readport (self->inport);
It seems that a LADSPA input port is basically a block of memory where
computed samples are written. The XAK input port, in contrast, is a structure
whose owning plugin queries it for a sample. In response, the port's feeders'
plugins' run() methods are invoked, who in turn query their input ports, and
so on up the chain. One complete chain reaction, driven by xak_readport()
above, constitutes a single sample run.
I have written Python bindings for XAK to facilitate test and experimentation,
and to simplify the construction of complex networks of plugins and lists of
events to drive them.
I get a sense from postings to this list that this group is primarily
interested in real-time synthesis. RT doesn't interest me so much at this
time, partly because I'm running on a clunky old 400MHz machine, and partly
because I'm more interested in the purity of the idea than I am in wringing
every last drop out of each machine cycle. The hardware will inevitably get
faster, but at least for now I'll be content to churn out gigabytes of sound
files.
- Pete