14 Aug
2003
14 Aug
'03
3:14 a.m.
> 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.
Sounds interesting. My system is similar but my audio paths are still
stereophonic
due to the large number of modules that rely on stereo pairs and you can
always
assign "control" channels to deal with an exception. I have a delay module
that
I have been working on that provides multile audio paths as you describe but
the
output is still in pairs. Ultimately I mix down to stereo anyway (I only
have
two ears). I know some audio systems support 6 channels for professional use
but
they are arrange in three stereo pairs.
> 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.
No difference according to my benchmarks - 0 difference
> 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.
I am a real time musician and I like the real time performance myself. I
also like those old analog modular synthesizers with patchcords and knobs
hanging all over the place and have never had the fun or precision in
setting
up a sound with digital synthesizers on the market today (although I love
my Korg ProTrinity X 8^) ). My interest is in real time response to
keyboards
and other controllers using (yuck) MIDI for now. LADSPA is interesting but
I do not see where it handles some of the issues of polyphonic voicing
and assignment control.
Soundslike you are having fun exploring the possibilities. Keep me informed
of your progress. There are a great number of audio software elements out
there and it is your sharing of ideas that brings new fruit to the table.
Do not be discouraged by those that tell you that we already did it and
why don't you use that. They are missing the point, aren't they! 8^)
Now go make noise.