[linux-audio-dev] XAP spec - early scribbles

[David Olofson]

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 ---