3 Feb
2003
3 Feb
'03
1:05 p.m.
On Monday 03 February 2003 16.42, Steve Harris wrote:
On Mon, Feb 03, 2003 at 04:12:19 +0200, Sami P Perttu
wrote:
Well, it is for chains of inserts among other things.
I think this is bad. There should be just one
process() function,
which could be given two gain values, one for previous output and
another for the plugin's own output. Plugins would do
out[i] = previous_gain * out[i] + gain * myoutput;
David is about to say non-mixing process() is a performance hack
;), but allways using this adds too much cost to fast
plugins.
Yeah, that's what I thought at first. However, if you track the
previous_gain and gain controls, you can select between a number of
optimized inner loops internally. What you get is basically the same
thing as a bunch of different callbacks, except that it's not part of
the API, and plugins can handle it any way they like.
Oh, you *do* have to check the control events for those two controls,
of course.
That said, I still think it seems easier to just provide a few
different callbacks of which plugin authors can pick one or more. A
fully optimized plugin would implement all of them, but you'll get
away with just one. It's not as flexible, but all the complexity is
in the host SDK; all you have to do in the plugins is copy/paste some
code. (Which I don't like of course, but really; if you want to
optimize, there's no other way, unless source level macro abuse
counts...)
//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://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---