On Monday 03 March 2003 09.57, [EMAIL PROTECTED] 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 ---