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

torbenh at gmx.de torbenh at gmx.de
Mon Mar 3 09:23:01 UTC 2003


On Mon, Mar 03, 2003 at 02:09:26PM +0100, David Olofson wrote:
> 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.

ok lets have the INPLACE flag and it will be fine...

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

ok this is nice.... 

> 
> 
> [...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.)

right... these are raw data events....

did you think about a type system for events...

typeof(raw event) != typeof(raw event)....

class hierarchy for events ?

the host should be able to forbid connecting an int output to a string input...
and the same for different raw events.

type coercion could be done by the host with implicit converter plugins.
to hide this from the event insertion code.

-- 
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language



More information about the Linux-audio-dev mailing list