Skip to content

Use MVerb by Martin Eastwood for reverberation#3787

Draft
dingodoppelt wants to merge 5 commits into
jamulussoftware:mainfrom
dingodoppelt:mverb
Draft

Use MVerb by Martin Eastwood for reverberation#3787
dingodoppelt wants to merge 5 commits into
jamulussoftware:mainfrom
dingodoppelt:mverb

Conversation

@dingodoppelt

@dingodoppelt dingodoppelt commented Jul 17, 2026

Copy link
Copy Markdown
Member

Short description of changes

This replaces the inbuilt reverb with MVerb by Martin Eastwood.

CHANGELOG: Use MVerb by Martin Eastwood for reverberation

Context: Fixes an issue?

This replaces the inbuilt reverb with a professional grade reverb algorithm:

MVerb is a free, studio quality, open-source reverb. Its release is intended to provide a practical demonstration of Dattorro's figure-of-eight reverb structure and provide the open source community with a high quality reverb.

Does this change need documentation? What needs to be documented and how?
Since we pull MVerb as a submodule build instructions are needed in COMPILING.md, similar to the Android build instructions.

Status of this Pull Request

Up for discussion

What is missing until this pull request can be merged?

As this has not been tested thoroughly I'd like to keep it a draft for now

Checklist

  • I've verified that this Pull Request follows the general code principles
  • I tested my code and it does what I want
  • My code follows the style guide
  • I waited some time after this Pull Request was opened and all GitHub checks completed without errors.
  • I've filled all the content above

@dingodoppelt dingodoppelt self-assigned this Jul 17, 2026
@dingodoppelt dingodoppelt added the feature request Feature request label Jul 17, 2026
@dingodoppelt

Copy link
Copy Markdown
Member Author

The builds fail, because MVerb was pulled in as a submodule and we seem to only clone them for android builds.

@pljones

pljones commented Jul 17, 2026

Copy link
Copy Markdown
Collaborator

The builds fail, because MVerb was pulled in as a submodule and we seem to only clone them for android builds.

I wonder if the sub-module clone can be repo-specific, so we can have one that only does liboboe for Android and another that does this for all platforms, included in the main clone step.

That suggests we also need build documentation changes included here.

@dingodoppelt

dingodoppelt commented Jul 17, 2026

Copy link
Copy Markdown
Member Author

I wonder if the sub-module clone can be repo-specific, so we can have one that only does liboboe for Android and another that does this for all platforms, included in the main clone step.

autobuild.yml currently handles submodules only for android, because oboe is our only submodule.
I have never had reasonable success with autobuilds on github, especially since I don't know how to properly test these scripts locally before releasing my embarrassing attempts to the world. Any advice on how to do that the right way?

That suggests we also need build documentation changes included here.

Haven't though about that but, yes, certainly.

Edit:
We could have Jamulus.pro check for existence of MVerb.h. If not found we can fail with an error message telling the user to run a target make submodules which would clone MVerb for all platforms and oboe only for android or just do it automatically. Just an idea because I just remembered typing make submodules at least once somewhere else.

@ann0see

ann0see commented Jul 17, 2026

Copy link
Copy Markdown
Member

how to properly test these scripts locally before releasing my embarrassing attempts to the world.

If it is not in .github they should be designed to build .deb/.dmg/.exe/.ipa/.apk I believe that this is not achieved at the moment. However, you can try and see where they fail.

@ann0see

ann0see commented Jul 17, 2026

Copy link
Copy Markdown
Member

For my taste, it is a bit too "far" .

@dingodoppelt

dingodoppelt commented Jul 17, 2026

Copy link
Copy Markdown
Member Author

For my taste, it is a bit too "far" .

It is nothing that is "needed" but the current reverb sounds horrible, tbh.
If we ever really needed a reverb (and I heavily doubt that) we should have used this in the first place or rip it out entirely, which would be my second choice after at least trying to improve things. Have you listened to MVerb in comparison to the current implementation?

@ann0see

ann0see commented Jul 17, 2026

Copy link
Copy Markdown
Member

Yes. I think the reverb implemented here (this PR) sounds too far. Yes, probably better than what we have at the moment.

@ann0see

ann0see commented Jul 17, 2026

Copy link
Copy Markdown
Member

Actually, we could also only include the reverb if the submodule was loaded.

@dingodoppelt

Copy link
Copy Markdown
Member Author

Yes. I think the reverb implemented here sounds too far. Yes, probably better than what we have at the moment.

I used one of the presets just to have at least something to start from. I'm not with my usual gear but will be tomorrow. I'll tweak some settings and try with different instruments and hopefully find a useful preset.

@dingodoppelt

Copy link
Copy Markdown
Member Author

Just a thought: We could easily expose the reverb parameters via JSON-RPC and store them in the .ini file

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

feature request Feature request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants