Support different reverb engines

[derselbst]

Related discussion

https://lists.nongnu.org/archive/html/fluid-dev/2022-05/msg00014.html

Is your feature request related to a problem?

I want to implement a reverbator that produces similar results as the Ultra 64 SDK.

Describe the solution you'd like

It would be nice to select different reverb engines when creating the synth. This would allow to re-enable the old freeverb engine, and for a potentially higher quality FDN reverb (by using 12 delay lines rather than only 8), and it would allow for a "Lexicon 224"-like reverbator, that I have been playing around with.

Describe alternatives you've considered

Alternative 1)
Feed the dry audio to some external program. This seems to have been suggested here (although I didn't fully understand how). In any case, this approach has the drawback that it would be almost impossible to get the amplitudes for the individual fx buffers right and therefore respect CC91 correctly.

Alternative 2)
Feed the dry audio to LADSPA plugins and process it there. Not sure if it would be possible to respect CC91 correctly. Additionally, Reinhold made the following note:

Using the LADSPA architecture on Windows is possible
according to the documentation, but dealing with an additional plugin (dll)
would have a wider impact (building, intregrating into installers). I guess
that the overall file size would be bigger than option (1). Setting the
reverb level per effect-groups (effect-group == midi channel == instrument)
is key when using the MIDI CC event 91 as reverb indicator for each
instrument.

Additional context

To implement this, one should rewrite the reverbator into an abstract C++ class, so that derived classes can implement a particular reverbator. Class template would allow to change previously hard-coded values like NBR_DELAYS.

The existing setting synth.reverb.active could be used to indicate which engine should be used at synth creation. Alternatively, yet another setting could be introduced.

@mawe42 FYI

[mmontag]

Strong vote for option 1 (Extend synth.reverb.active from boolean to an enum integer, to allow
selecting different reverb engines when the synth is created).

Different reverb options would be great. BTW, do you know any open source implementations with a Lexicon 224-like architecture?

[derselbst]

BTW, do you know any open source implementations with a Lexicon 224-like architecture?

Unfortunately not. But I've seen a simple one in the N64 dev kit, which we may use as "source of inspiration".

[mmontag]

I found some useful info in the freeverb3 reference docs: https://freeverb3vst.osdn.jp/ref.shtml

• Brief history of Lexicon reverbs: https://gearspace.com/board/high-end/362930-lexicon-reverbs-brief-bestiary.html
• Progenitor reverb http://git.savannah.gnu.org/cgit/freeverb3.git/tree/freeverb/progenitor.cpp
  • described as "Simple Tank Reverb with modulation - An original type of a plate reverb algorithm in the Lexicon 224 as developed by David Griesinger."
  • https://freeverb3vst.osdn.jp/doc/Progenitor.jpg