Subject: Re: [linux-audio-dev] XAP spec - early scribbles
From: David Olofson (david_AT_olofson.net)
Date: Mon Mar 03 2003 - 15:09:26 EET
On Monday 03 March 2003 09.57, torbenh_AT_gmx.de wrote:
[...inplace processing...]
> > Just consider multichannel plugins. These are often inplace safe
> > within channels, but *not* across channels. This is a result of
> > channels being processed one at a time, rather than all in
> > parallel.
>
> a multichannel plugin only makes sense if the channels depend on
> each other.
(I'm not sure I agree, but that's besides the point.)
Channels having "internal affairs" doesn't imply that the whole plugin
processes one frame at a time, all channels in parallel.
[...adding and replacing process()...]
> plugin -> gain
> \
> plugin -> gain----- out
> /
> plugin -> gain
>
> if run_adding was optional it would be ok for me...
Right.
Actually, since we're dealing with multichannel plugins (as opposed to
single channel mono or stereo), it doesn't really make sense to use
different callbacks. What if the hosts wants adding for some outputs
and replacing for others?
It's been suggested that we should just define a standard
"OLD_GAIN"/"OUTPUT_GAIN" control pair, and let plugins that have them
decide what to do based on the values. For example;
OLD_GAIN = 1.0, OUTPUT_GAIN = 1.0 ==> adding
OLD_GAIN = 0.0, OUTPUT_GAIN = 1.0 ==> replacing
OLD_GAIN = 1.0, OUTPUT_GAIN = 0.5 ==> mixing at -6 dB
Plugins that have these controls would at least have to implement the
generic fallback case:
out[i] = out[i] * OLD_GAIN + generated[i] * OUTPUT_GAIN;
Then they could add special cases for 1.0, 1.0 (no multiplications),
0.0, 1.0 (replacing) and maybe other variants, when they make sense.
Checking would be done only when events for these controls are
received; not in the inner loops. The API doesn't have to specify any
specific modes or anything, and hosts just look for the controls and
use them, or fake them if they're not supported.
[...audio rate control events and stuff...]
> this idea is not feasible for XAP...
> i would only give it a try for a small plugin set consisting of
> osc, dc, filter, delay...
Well, it could probably be implemented as a "custom protocol" on top
of XAP, but that would mean that you have to include converters to
and from this protocol to be able to connect these plugins to
ordinary XAP plugins. "Private" talk among these plugins shouldn't be
a major issue. (Well, hosts will have to provide RT safe memory
management of some kind, but we'll most probably need that anyway,
for string and raw data controls.)
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`-----------------------------------> http://audiality.org -'
--- http://olofson.net --- http://www.reologica.se ---
This archive was generated by hypermail 2b28 : Mon Mar 03 2003 - 15:05:24 EET