v5 pre-release: multi-track drift fix, more self-tests, logging, CLI, version bump

Multi-track recording drift fix (Ed's question — can the separate tracks drift over an hour?):
* Root: FlushPeerTracks skipped a peer that produced no samples in a render block, so a peer that
went quiet long enough for its session to be pruned (>4 s idle) would have its track fall behind
and desync. Now every peer track is padded to a full render block each cycle (silence when the
peer produced nothing), so all peer tracks stay sample-locked to the single render clock — they
can't drift apart however long the recording runs, and all end the same length. Same padding for
the single-file bypass path. OnRecordBlockComplete now carries the block's float count.
(The peer tracks are already resampled to the render clock per peer, so this makes peer-to-peer
sync exact; your own "me" track is capture-clocked — same soundcard for capture+playback = same
clock = no drift, different interfaces can drift slightly.)

* Self-test: two new steps — "Per-peer shaping DSP" (PeerDspChain unity/master-off/volume/parametric
+ ParametricToPeaking) and "v5 settings and shaping round-trip" (AppConfig defaults, NamedPeers,
MainTabOrder, parametric PeerShaping, recording default = Both).
* Logging (gated by the logging checkbox): master shaping switch, EQ-mode change, parametric band
add/delete, peer rename/clear/delete, and the applied Appearance settings after Preferences close.
* CLI: --list-profiles and --list-named-peers (read-only), in --help.
* Version bumped to 5.0; About-box changelog, RELEASE_NOTES.md and README updated for v5.

Build clean; --selftest passes.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

This commit is contained in:

Ednunp

2026-07-08 18:19:01 +01:00

co-authored by

Claude Opus 4.8

parent fcc3cdc793

commit aeca24ae17

10 changed files with 193 additions and 31 deletions

									
										src/RemSound.App/RemSound.App.csproj
									
		+1
		-1
	
												View File
												
				@@ -18,7 +18,7 @@

				         tag_name on the latest GitHub release; bump it on every public release. The

				         AssemblyVersion / FileVersion default to this value, and Assembly.GetName().Version

				         is what the About dialog and the updater both read. -->

				    <Version>4.9</Version>

				    <Version>5.0</Version>

				  </PropertyGroup>

				  <ItemGroup>