jensandClaude Sonnet 5
ab29ad2820
- README.md: what the tool is and isn't (generic, not JaySynth-specific), build instructions, CLI quick-start, full JSON scenario schema/field reference, the patch/bank state-format caveat (this tool's load/save goes through JUCE's host-side AudioPluginInstance state calls, not JaySynth's own GUI-triggered loadPatchFromFile/patchImportXml - a different code path worth knowing about), and an architecture summary. - TODO.md: tracks what's deferred by design (LV2/VST3/LADSPA format registration, Windows build), test coverage gaps (stereo effects untested, no regression-baseline tooling, no CI wiring, no JSON-parser unit tests, no polyphony testing), two things worth investigating (a non-fatal DPF plugin assertion seen on load, an unconfirmed WavAudioFormat channel-count limit), and one nice-to-have. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011dhtwRLARk4eiPngcQykLJ
4.0 KiB
4.0 KiB
testhost TODO
Tracks known gaps and future work for tools/testhost/, the generic headless
plugin test host (see README.md for what it does and how to use it, and
/home/jens/.claude/plans/sharded-finding-tower.md for the original design
plan). Nothing here blocks current use — Phases 1-4 of the plan are done and
verified (PR #1).
Deferred by design (Phase 5 of the plan)
- LV2 plugin format support. JUCE 3.1.1 (the version currently
vendored at
sdk/juce/JUCE-3.1.1) has no LV2 hosting backend. Once JaySynth's own JUCE dependency is upgraded (or a customAudioPluginFormatsubclass is written against the current version), register it inPluginHost's constructor alongsideVSTPluginFormat- no other host code should need to change, since everything downstream talks to the format-agnosticAudioPluginInstance/AudioProcessorAPI already. - VST3/LADSPA format support. JUCE already ships
VST3PluginFormat/LADSPAPluginFormatin this same vendored version - registering them is a one-line addition toPluginHost's constructor, just not done yet since nothing has needed it. - Windows build (
Makefile.win). The plan calls for mirroringsrc/plug's Linux/Windows Makefile pattern; only the Linux side has been built and tested so far.
Test coverage gaps
- Only mono (1 in/1 out) and asymmetric (2 in/1 out) effect channel
configs have been smoke-tested (
ZamDelay-vst.so,ZamComp-vst.so,ZamEQ2-vst.so). A genuinely stereo-in/stereo-out effect hasn't been run through yet - worth doing before relying on this tool for a stereo effect plugin specifically. - No automated regression baseline comparison. The plan's stretch
goal: batch-render every
.fxp/.xmpunderextras/sounds/through a fixed note pattern and diff against stored baseline WAVs/checksums, to catch DSP or save-load regressions automatically instead of via one-off manual runs. Not built. - No CI wiring. Nothing currently runs
testhostautomatically on push/PR; it's a manual, opt-in tool for now. - No unit tests for
TestScenario's JSON parsing itself (malformed JSON, missing required fields, wrong types, out-of-range values) - only exercised indirectly via a couple of hand-written scenario files during development. Edge-case handling (e.g. a negativesample, an unterminatednoteOnwith no matchingnoteOff) is untested. - Polyphony/multiple simultaneous notes untested - only ever a single held note in all smoke tests so far.
Investigate
- DPF-based plugins print a non-fatal assertion on load. All three
Zam*-vst.so plugins tested (built with the DISTRHO Plugin Framework) print
assertion failure: "fIsActive" in .../DistrhoPluginInternal.hppduringPluginHost::load(), despite JUCE'sVSTPluginInstance::prepareToPlayalready sendingeffMainsChanged/effStartProcess. Rendering still completes correctly (confirmed via WAV output), so this looks like a DPF/JUCE VST2 lifecycle-ordering quirk rather than a testhost bug, but it hasn't been root-caused - worth a closer look if it turns out to affect correctness (not just log noise) for some other plugin. WavAudioFormat's base-class doc comment says channel count "must be either 1 or 2" (AudioFormat::createWriterFor's Doxygen comment).WavRecorderpasses through whateverPluginHost::getNumOutputChannels()reports with no clamping, and this has worked fine for the 1- and 2-channel plugins tested so far - but a plugin with more than 2 output channels hasn't been tried, so it's unconfirmed whether JUCE's WAV writer actually enforces that limit or the doc comment is just generic/stale boilerplate shared across format subclasses.
Nice-to-have (not planned, just noted)
- A
--list-paramsor similar introspection mode (print every parameter's index/name/current value) would help writing new scenario JSON files without cross-referencing the plugin's own GUI or source.