Subject: Re: [linux-audio-dev] XAP spec - early scribbles
From: torbenh_AT_gmx.de
Date: Mon Mar 03 2003 - 12:38:47 EET
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
This archive was generated by hypermail 2b28 : Mon Mar 03 2003 - 16:20:19 EET