Open
Conversation
Co-authored-by: derselbst <8152480+derselbst@users.noreply.github.com>
Co-authored-by: derselbst <8152480+derselbst@users.noreply.github.com>
Co-authored-by: derselbst <8152480+derselbst@users.noreply.github.com>
Co-authored-by: derselbst <8152480+derselbst@users.noreply.github.com>
Co-authored-by: derselbst <8152480+derselbst@users.noreply.github.com>
Co-authored-by: derselbst <8152480+derselbst@users.noreply.github.com>
Co-authored-by: derselbst <8152480+derselbst@users.noreply.github.com>
Co-authored-by: derselbst <8152480+derselbst@users.noreply.github.com>
Co-authored-by: derselbst <8152480+derselbst@users.noreply.github.com>
Co-authored-by: derselbst <8152480+derselbst@users.noreply.github.com>
Co-authored-by: derselbst <8152480+derselbst@users.noreply.github.com>
Co-authored-by: derselbst <8152480+derselbst@users.noreply.github.com>
Co-authored-by: derselbst <8152480+derselbst@users.noreply.github.com>
Co-authored-by: derselbst <8152480+derselbst@users.noreply.github.com>
Co-authored-by: derselbst <8152480+derselbst@users.noreply.github.com>
This was referenced Feb 22, 2026
Contributor
|
Congratulations on breaking through with an item that has been on your wish list for a long time! I know this will be a very welcome enhancement in the virtual organ world. I look forward to enhancing the Miditzer so that it can offer access to a menu of reverb types. I think the addition of a synth.reverb.type string setting for selecting the reverb engine is most in keeping with other settings of this type. The default would be FDN, so not breaking if no setting is made. synth.reverb.active would continue to enable/disable the reverb engine regardless of the engine selected. The advantage of a string setting from my perspective as an app developer is that it allows me to query FluidSynth for the available reverb engines and build a dynamic menu of reverb engine choices. If integers are used as selectors, I would keep a static table of the names that correspond to the selector. |
Contributor
|
One thing I thought of, something I couldn't find in the current API. That is, something like Thoughts? |
Member
Author
|
Member
Author
|
Based on @jimhen3ry suggestion, I've added a string based setting to switch reverbators and called it I'm intending to bring this up on our mailing list in the upcoming days. |
Contributor
|
I think that it should be noted for FDN that it can create distortion in some cases (like the finger snap sample). Also:
Wouldn't it make sense for FDN to default to 12 delay lines now, since there are even more CPU-expensive engines? (like Dattorro) |
Member
Author
I'll do that.
I see no benefit in increasing it to 12 delay lines. Compared to the Lexverb and Dattorro, FDN is way inferior. Also, the regression tests show that it has quite some impact and I do know at least one user around here who wouldn't be quite happy about unnecessary changes in sound. (PS: To get a feeling for the values below: while messing around with Lexverb's damping I saw an SNR of 30 - 40, but never less than that): Details |
Contributor
I agree, esp. with the finger snap. I believe it is very important for the default reverb algorithm to be the most mature one, as most programs will probably stick to defaults, or users will just run The only problem I could see here is the increased CPU usage, though for such extreme cases where that really matters, the users can switch back to Freeverb or FDN. What do you think? |
Member
Author
You mean
It'll be one of the questions I'll be posting to the mailing list. The behavior of the reverb settings is still quite different for the two compared to FDN. I cannot decide this on my own. |
Contributor
Asking the community is a good idea, though wouldn't GitHub discussions be a better place for this? Similarly to the modernizing development tools thread. |
derselbst
force-pushed
the
multi-reverb-support
branch
from
b91b6f3 to
df6b368
Compare
This was
linked to
issues
Mar 14, 2026
|
Member
Author
|
I announced that topic on our mailing list and on Github discussion. Feel like an eternity. No feedback so far, just 3 upvotes. If it stays that way I will merge it as is, i.e. keep all four engines for now and keep FDN as default engine (to remain compatible in how the reverb parameters behave / influence the reverb sound). I'll reserve the option to remove freeverb in a future release again, as it sounds worst compared to the others. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR implements my idea posted in #1157: Providing multiple built-in reverb engines. In effort to fix problems #1496 and #1215.
TL;DR: Check out the new reverb overview with audio samples in the API docs.
This PR currently adds 3 additional reverb engines to fluidsynth, which can be selected via the new setting
synth.reverb.engineor via the-Rflag for convenience:-R fdn- The default FDN reverb-R free- Fluidsynth's pre-2.1.0 reverb "Freeverb"-R lex- LEXverb-R dat- Dattorro ReverbThe existing FDN was used to derive a C++ base class from it, which every engine inherits from, to provide a common interface for
rvoice_mixer.Users who are interested in testing the reverbs themself - with optional parameter tweaking - can do so by building the
renderReverbOverviewCMake target, which will render audio tobuild/test/manual/reverb/.Implementation details of the reverbators can be obtained from the liked papers from the API docs, or from the source code / header file, which may or may not include a block chart in ASCII art.
Breaking Changes
synth.reverb.dampsetting was changed to0.3. After having played around a lot with reverb in the last weeks, I conclude that this was a mistake. At least for the default FDN reverb, damp=0.3 always sounds too much like a garage or metal bucket to me. This PR changes the default damp value back to0.TODO
synth.reverb.level- is there a better approach to this?synthinvolvingwith_reverb,fluid_synth_reverb_on()etc should be revised / simplifiedI should add that ChatGPT-5.2 was a huge help and time safer to get all those different implementations plugged together and integrated into fluidsynth's 4-reverb-settings universe. Something that was unthinkable when I initially brought up this topic on our mailing list almost four years ago.
Resolves #1157, #1496, #1215