Add jamulusclient/setInputBoost JSON-RPC method

[mcfnord]

MY LLM WROTE:

Adds jamulusclient/setInputBoost so headless clients can change the input boost factor at runtime, matching what the GUI's Advanced Settings combo box already does.

Requested by @pljones on #3841: "add the JSONRPC to match the Client UI first, then this one. I'd rather not introduce a hole." This is that first PR; #3841 (the ini-parse fix) follows it.

What it does

{"boost": <1-10>} calls CClient::SetInputBoost() directly — the same call the GUI makes from CClientSettingsDlg::OnInputBoostChanged (clientsettingsdlg.cpp:1385-1389) on every combo-box change. The factor is 1-based, where 1 is the GUI's "None", matching cbxInputBoost's population in clientsettingsdlg.cpp:549-556.

Validation mirrors the existing setMuted handler. docs/JSON-RPC.md is regenerated via tools/generate_json_rpc_docs.py.

Testing

Built headless (qmake CONFIG+=headless && make), then ran a real headless client (jackd -d dummy, -n --jsonrpcport ... --jsonrpcsecretfile ...) and drove the method over the TCP JSON-RPC socket — not just a startup smoke test:

Request	Response
{"boost": 10}	{"result": "ok"}
{"boost": 1}	{"result": "ok"}
{"boost": 11}	{"error": {"code": -32602, "message": "Invalid params: boost must be between 1 and 10"}}
{"boost": 0}	{"error": {"code": -32602, "message": "Invalid params: boost must be between 1 and 10"}}
{"boost": "x"}	{"error": {"code": -32602, "message": "Invalid params: boost is not a number"}}
{}	{"error": {"code": -32602, "message": "Invalid params: boost is not a number"}}

Each response carries result or error, never both — checked explicitly, since that was the bug fixed in #3820.

Note

There is no getInputBoost: client.h:290 defines only the setter, so a consumer can set the boost but not read it back. Several other RPC settings have the same asymmetry, so I left it out of this PR rather than address it piecemeal — happy to follow up if you'd like it covered.

[dingodoppelt]

I don't think we should mix in some headless only options. I use client RPC only with the GUI (while I've never used the boost feature)
Alternatively (as with the reverb): get rid of the boost feature, because I doubt it sees much use.

[ann0see]

because I doubt it sees much use.

Likely.

I discussed this with @hoffie as this was introduced initially. The problem was that some windows laptops had very quiet mics. With an ASIO4ALL setup this was necessary.

Our ensemble side stepped this by giving everyone a budget interface + mic with real ASIO driver.

[pljones]

Yeah, it's another one of the "features" that - in my opinion - is pure bloat. The problem it addresses can - and should - be fixed outside Jamulus.

On this change -- when there's a change triggered by either the UI or JSONRPC, that change should send a signal and that signal should trigger the UI to change and a JSONRPC notification to be emitted. I believe that's the template we follow generally?

[dingodoppelt]

On this change -- when there's a change triggered by either the UI or JSONRPC, that change should send a signal and that signal should trigger the UI to change and a JSONRPC notification to be emitted. I believe that's the template we follow generally?

I don't think there is a general template, yet. There definitely should be one. Having the input boost not reflected in the UI was just "bad luck". For example with setMuted I reused the MIDI implementation and that already updated the UI.