0.16 review: standalone settings persistence and output channel policy

[defiantnerd]

Third batch from the 0.16 release review of main...next. Independent of #545 and #546.

What is here

SA-2 and SA-4 — one bug wearing two hats. captureAudioSettings() wrote the resolved device names and used-flags back to disk. Those describe the stream as it was actually opened, not what the user asked for: resolveOutputDevice() falls back to the default when the saved device is absent, and startAudioThreadOn() clears the used flag when a side cannot be opened. Since saveSettings() runs on every window move and on WM_DESTROY, the fallback was persisted before the user could ever notice.

• SA-2: launch once with your interface unplugged and outputDeviceName becomes Speakers (Realtek). Plug it back in and you are on laptop speakers, with no indication why.
• SA-4: first run inside an RDP session with audio redirection off saves audioOutputUsed=false, and applyAudioSettings() ANDs the stored flag with the probe — so output is disabled on every later launch at the console, while the settings panel cheerfully shows the default output selected.

Reading every use of audioOutputUsed showed it was really runtime state ("open this side now"), clobbered by three different functions, with genuine user intent only ever entering through the mute menu and the device combos. The two meanings are now separate: settings.* holds intent, written by the frontend at the point of choice — the same split openMidiPorts() already had with settings.midiPortNames — and the runtime flags are recomputed as intent AND probe each launch and never persisted.

Side effect, and an intended one: the mute-input check mark now reads intent, so it no longer goes stale on a machine with no capture device, and a mute survives an API switch — which the check mark already claimed it did.

SA-3 — a hand-edited config could terminate the process. clapProcess() calls std::terminate() if a callback delivers utilityBufferSize frames or more, RtAudio opens a WASAPI stream at whatever size it is asked for, and standalone_settings.h advertises the .conf as the supported way to configure a build with no settings UI. bufferSize=100000 took the standalone down on the first callback. Now clamped to the largest size the settings panel itself offers. The std::terminate stays — it is a real invariant for the utility buffers; the fix is to never reach it. Sample rate was checked and needs no clamp; the reasoning is recorded next to it.

SA-5 — surplus output channels carried a duplicated channel. The interleave repeated the plugin's last main-bus channel into every surplus device channel. Indistinguishable from a mono rule while devices were always opened with two channels — but the Windows frontend now opens them at full channel count, so a stereo plugin on an 8-output interface put its right channel on outputs 3 through 8, a hard-right signal into whatever those feed (typically a cue mix or a second monitor pair).

New policy: a mono bus duplicates onto the device's first two channels, anything else maps channel-for-channel up to min(bus, device), and every device channel the plugin does not address is silent.

The input path is deliberately unchanged

It uses the same repeat-last rule in the other direction: a plugin input bus wider than the device repeats the last device channel into the surplus (mono mic → both channels of a stereo bus, but a stereo device into a 6-channel bus puts the right input on bus channels 3–6), and a device wider than the bus has its surplus dropped (a stereo plugin on an 8-in interface reads inputs 1/2 only).

That has different ergonomics from the output case and nobody has reported a problem with it, so it is left for a separate decision. The comment that claimed output and input shared one policy is corrected rather than left to mislead.

Reported, not changed

A saved sample rate the device does not support still falls back to preferred, and that fallback is persisted — the same class as SA-2. An input-only stream with a garbage rate reaches openStream(), which errors rather than crashes.

[baconpaul]

Again this code is all fine but we really do need to do a comments cleanup pass