14 Aug
2003
14 Aug
'03
7:09 a.m.
On Wed, Aug 13, 2003 at 08:09:19 -0400, Paul Davis wrote:
So does sfront, SyncModular and and lots of hardware systems. You can do
it efficiently in software if you downcompile the modules to a processing
loop at runtime, c.f. the linuxsampler project.
The is an area where we can really beet the closed source guys as we have
no issues with giving away out DSP code.
- Somewhat
related to the item above, a plugin's run() method computes exactly
one sample at each call, not a block of samples. This is again a matter of
perry cook's SDK does this too. everybody knows its cool, just as
everybody knows its incredibly inefficient. you have 100% of the
overhead of a chain of function calls for every sample. for anything
except trivial processing, its too expensive to be useful for a
general purpose API (for now). per-sample processing isn't a feasible option as a
general API model
for, oh, i'd guess at least another 3-4 years. and many operations
that want to work in the frequency domain require blocks anyway, and
so are not helped by this design.
NB nor by the current design of blocked systems, the FFT, WSOLA, etc.
requirements are a bit odd.
>transparently, according to the port's
configuration. I believe this
>simplifies use of the system and eliminates the need for a special
>runAdding() plugin method.
My suspicion is that runAdding et al is just unneccesary (c.f. cache
effects), but I haven't benchmarked it.
- Steve