On Wed, 5 Feb 2003, David Olofson wrote:
Q: Where do multiple versions of process() make
sense?
A: In small plugins that are likely to be used in many instances.
Q: When do you desperatly want to avoid any added complexity?
A: When implementing large "monolith" type plugins, that generally
lots of CPU and/or very rarely will be used in more than one
instance.
There might be one problem though: Monoliths may have lots of audio
ins and outs, which again means per-buffer overhead might start to
matter... Not sure if your average user would use enough audio ports
that this really matters, though. (Audiality certainly won't need
many external ports if you're using the internal mixer for FX, but I
would think that most synths with less strange backgrounds and
motives don't even have internal FX.)
The more I'm thinking about this the more biased I am toward just one
process() that replaces values. And an in-place-is-okay hint. No gains or
DRY and WET controls. The host can probably reserve some host-global
buffers for mixing, no? The cache impact wouldn't be big in that case.
Somebody should do some actual measurements to find out.
A small but seemingly annoying can of worms is the case when you have WET
and DRY, more than one audio output, and some of the outputs use the same
buffer. Now you have to impose that the plugin write its outputs in the
right order to enable the host to calculate suitable DRY controls.
...pitch...
I'm still having problems understanding why logarithmic frequency is
better than linear. Doesn't it violate the principle of keeping plugins as
simple as possible? Most plugins need linear frequency. How is the
conversion done? Well, maybe there could be a control iterator that
provides for it. Please tell me about your plan.
--
Sami Perttu "Flower chase the sunshine"
Sami.Perttu(a)hiit.fi
http://www.cs.helsinki.fi/u/perttu