On Monday 03 February 2003 16.42, Steve Harris wrote: > On Mon, Feb 03, 2003 at 04:12:19 +0200, Sami P Perttu wrote: > > 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 > ;),
Well, it is for chains of inserts among other things. > 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 ---
