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