Re: [fluid-dev] Trying another reverb ?

[Marcus Weseloh]

Hi,

2017-10-25 0:10 GMT+02:00 Ceresa Jean-Jacques <address@hidden>:

However Reverb and Chorus consumes memory, so for small embedded system it will be necessary that only the reverb/chorus in use are loaded . So this system must uses the RTL API (run time loading library) of the OS concerned. These API aren't compicated (around 3  functions maximum). Again we fall into the problem of OS dependency but it is necessary.

You are right, embedded systems are (still) space constrained. But bundling two or more different implementations does not necessarily mean huge memory consumption. The effect implementations would just need to make sure that they only allocate memory when actually chosen at FluidSynth startup. So the only resources they take up when not used would be the compiled code itself. And to cater for the *very* constrained users who need an extra small FluidSynth library, we could even add compile-time switches to take them out.

If we start to add dynamic loading to the idea, then we've basically reinvented LADSPA :-)

Speaking of which: Kjetil made a very good point about LADSPA not necessarily being Linux-only. It is a very simple API, compile time dependency is a single header file. So if we change the dynamic library loading code in the FluidSynth LADSPA binding, we would be just where you wanted to go.

I'm doing the last remaining changes to the new LADSPA code to enable effects to access the "proper" reverb send data (the voices mix that takes the reverb send from the SoundFont / generator into account). As soon as that is done (and I've finished the documentation), custom reverbs can be easily added by switching off the internal reverb and using a LADSPA plugin.

So let me take back my "internal effects API" idea. It was mainly inspired by the prospect of even more #ifdefs or switches in the core codebase anyway.

Looking forward to listening to your reverb, thanks for posting!

Cheers,

    Marcus