Subject: RE: [linux-audio-dev] exploring LADSPA
From: Brad Arant (barant_AT_barant.com)
Date: Thu Aug 14 2003 - 08:00:28 EEST
>> 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.
This archive was generated by hypermail 2b28 : Thu Aug 14 2003 - 08:02:42 EEST