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)

[ignotus666]

@dingodoppelt It shouldn't be too hard to add a preset dropdown to the UI.
On the topic of effects, I've been working on an experimental branch for personal use that has an effects dialog with reverb, compression and EQ. It saves presets, so maybe you can have a look at that part. The UI is modified but the principle should be the same. I'm going to be super busy for the forseeable future so unfortunately can't be of much help. I try to keep the branch up to date and generate Win, Mac and Linux builds.
Branch
Builds

Edit: Never mind, I see it's been added.

[ann0see]

Thank you for adding the UI. For me it was quite confusing (while singing) still as I had the feeling that intonation was way harder. But it seems to depend on the selected preset.

There was also #3379 (moving the reverb slider to advanced settings) which I think we should do some day. The reverb is not used often - I suppose. And I think it clutters the UI.

[dingodoppelt]

There was also #3379 (moving the reverb slider to advanced settings) which I think we should do some day. The reverb is not used often - I suppose. And I think it clutters the UI.

Good idea. Alternatively get rid of the reverb altogether. With this change I hope the reverb sees a little more use. We'll hear ;)

[ann0see]

If this was a new feature, I'd argue that it probably violates the do one thing and do it well approach - unless we add full plugin support.

[dingodoppelt]

If this was a new feature, I'd argue that it probably violates the do one thing and do it well approach - unless we add full plugin support.

I don't think we should go full plugin support. We'd be writing a plugin host and there must be a reason why there aren't many. If we made Jamulus a plugin (Linux already does that) users could load it into their effects chain and have all plugins working and not only the chosen few JamulusVST would be able to provide. I think I've mentioned DPF already in that respect.

[pljones]

If we made Jamulus a plugin (Linux already does that)

Eh? You mean Jack? Which is on Windows as well. As is ReaRoute. And similar solutions on macOS.

To make it clear: I see the problem as two-fold. What I want others to hear as an effect to my input and what I don't want others to hear but I want to hear as an effect to my input. (To be even clearer: neither of those applies to the server mix returned.)

<audio in> -> <inline effect> -> Jamulus -> (everyone including) me

<audio in> -- --------------- -> Jamulus -> (everyone including) me
   \_ -> <send effect> -----------------------------> <return> _/

I don't think either of these belongs in Jamulus. Whilst having "soft reverb on my vocals makes me feel more comfortable" might work for "what I hear", it doesn't necessarily work in the mix (causing it to get muddy at times).

I think there's still a perception that the mixing desk actually controls something other than a single audio signal that's received from the server. That leads to an idea that having "effects in Jamulus" would allow per-channel routing to those effects. Of course, that's not structurally possible.