Hi,
2017-10-25 0:10 GMT+02:00 Ceresa Jean-Jacques <jean-jacques.cer...@orange.fr
>:
> 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
_______________________________________________
fluid-dev mailing list
fluid-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/fluid-dev
