Re: [Linuxsampler-devel] recompilation and inlining LADSPA speed issues, looping, enveloping

[Benno S. <be...@ga...>]

Ah interesting, so there are problems when the inner loop is getting to
big.
Any ideas what the best compromise looks like (of course it depends from
the cache size but it would be cool to have a method to figure it out).
We could run some heurystics tha tries to break a large signal
processing chain into smaller loops till best performance is achieved.

regarding the CV stuff. Is CV the ideal (and efficient) model to use in
a sampler ? Excuse my ignorance but I have not a big familiarity with
the CV paradigm (everything is a control value), any useful URLs that
 handle his topic ?

cheers,
Benno


Steve wrote:

> in linuxsampler it would be better to process all in a single pass
> eg:

Not neccesarily, once the inner loop goes over a certain size it becomes
/very/ inneficient. Infact one of the common ways of optimising bigish
plugins is to break them into smaller passes.

Obviously you wont win every time, but I think inlined finction calls to
LADSPA run() routines will be faster on average.

Obviously, things like mixers should be native, but not for eg. ringmods
(multipliers), a decent ringmod has antialiasing code in (though mine
doesn't, yet).

> An additional issue about LADSPA is that it is only suitable for audio
> processing but not for midi (or event)-triggered audio generation.

No, its not suitable for MIDI, but it can certainly do unit generation,
infact AFAIK the only bandlimited oscilators for Linux are LADSPA
plugins.
You just the the CV model for triggering.

- Steve