3 Mar
2003
3 Mar
'03
10:22 a.m.
On Mon, Mar 03, 2003 at 02:09:26PM +0100, David Olofson wrote:
On Monday 03 March 2003 09.57, torbenh(a)gmx.de wrote:
[...inplace processing...]
(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...
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.
[...adding and replacing process()...]
ok this is nice....
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...]
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 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.)