linuxsampler-devel

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

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

[Steve H. <S.W...@ec...>]

On Tue, Oct 29, 2002 at 07:50:32 +0100, Benno Senoner wrote:
> Ah interesting, so there are problems when the inner loop is getting to
> big.

Yes, mostly for the cache reasons you mentioned.

> 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).

I think it would be hard/bad to try. Refactoring C(++) code is really
hard, I think its best to leave it as atomic as the DSP programmer made
it. You wil be supprised how efficient it is, modern CPU are heavily
optimised for small loops.

> 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 ?

Hard to say if its efficient. It's a tradeoff, it hadles some things very
well (ie. rapidy, unpredicatbly or continuously changing control values),
but it handles things that are mostly constant less efficiently than event
based systems.

I like it becasue it is easy to understand, model and process, and it has
good worst case performance.

I dont know of any resources, but the principal is very simple.
Frequencies are represented as an exponential scale of octaves, amplitudes
and time linearly. This covers everything and is very modular.

The obvious system for a sampler would be events for MIDI notes generating
sample buffer activity, and CV for internal parameter control. This should
get the best of both worlds. It is how SSM works, and that is very
efficient and versatile.

I am biased in favour of CV, so you should mayeb look for some oposing
arguments, I'm not aware of any ;)

- Steve