Use MVerb by Martin Eastwood for reverberation

[dingodoppelt]

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.
• Since the introduction of presets we might need documentation for that.
  Corresponding PR: Add documentation on advanced settings->reverb preset jamuluswebsite#1153

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]

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

Edit: fixed

[pljones]

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]

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]

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]

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

[dingodoppelt]

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]

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

[ann0see]

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

[dingodoppelt]

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]

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

[pljones]

You should be able to test the autobuild scripts on your own repo without raising a PR by pushing to a branch starting with "autobuild" -- I think.

[dingodoppelt]

You should be able to test the autobuild scripts on your own repo without raising a PR by pushing to a branch starting with "autobuild" -- I think.

Yes, that works. But I meant locally as in my machine. I found something which involved containers and didn't work for windows so I guess I'll stick to my github repo.

[ann0see]

It should definitely have the presets as configuration option in the Advanced Setup screen too.

[dingodoppelt]

It should definitely have the presets as configuration option in the Advanced Setup screen too.

I wasn't too sure about how to handle this. Either make it JSON-RPC exclusive or have power users and nerds edit their INI files, which is dead easy. I didn't want to bloat the UI with a setting nobody actually requested.
I've never worked on UI things so that might take a little while to get into. I just got the autobuilds fixed so I'll push that first.

[ann0see]

I also only have limited UI understanding. I think @ignotus666 knows more.

[dingodoppelt]

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

I guess this is due to the "predelay" parameter setting. I chose a preset with no pre-delay.
We can always add new presets but I just copied those from the VST plugin for now.

[dingodoppelt]

It should definitely have the presets as configuration option in the Advanced Setup screen too.

Done

[dingodoppelt]

• Linux amd64 works (tested debian autobuild binary and local arch linux build with gcc16 and qt6)
• Android works (tested on Android 17/GrapheneOS)

[ann0see]

After some more thinking: I think we should indeed detect if the submodule was cloned. If not the reverb feature should be hidden and while running qmake a warning should be issued.

I suspect that you could check if the folder contains the reverb code and if not set pre processor flags -> use ifdefs in the code to remove the reverb functionality. For the UI hide or remove it it if reverb is not compiled. I would personally not use reverb even in this upgraded state.

[dingodoppelt]

After some more thinking: I think we should indeed detect if the submodule was cloned. If not the reverb feature should be hidden and while running qmake a warning should be issued.

I suspect that you could check if the folder contains the reverb code and if not set pre processor flags -> use ifdefs in the code to remove the reverb functionality. For the UI hide or remove it it if reverb is not compiled. I would personally not use reverb even in this upgraded state.

I'd then argue it should be on by default and a qmake option noreverb should be introduced. We could clone the submodule if it isn't there and noreverb isn't set.

[ann0see]

Maybe yes.

Better ask the user: Reverb not found. Want to clone?

[pljones]

Better ask the user: Reverb not found. Want to clone?

No, qmake and make aren't interactive processes. You pass flags.

[ann0see]

Ok. Fair point.

[dingodoppelt]

Maybe yes.

Better ask the user: Reverb not found. Want to clone?

QMake will try to clone the submodule if it can't find it and noreverb is not set. If the clone fails it will fall back to noreverband build nonetheless. It could be argued we want to fail instead because the user intended to build with reverb because noreverb wasn't set.

Edit, a small excerpt from the autobuilds:

Submodule 'libs/mverb' (https://github.com/martineastwood/mverb.git) registered for path 'libs/mverb'
Cloning into '/home/runner/work/jamulus/jamulus/libs/mverb'...
Submodule path 'libs/mverb': checked out '9f9512e9d990fcf265e00fc7c2ee47ad20c8019f'
Project MESSAGE: building with MVerb

[ann0see]

Weirdly no reverb seems to hide the pan pots on macOS.