Bump the DspTap pin to 28a34a1 - #25
Merged
Merged
Conversation
Refreshes submodules/dsptap from 9cbfbca to 28a34a1, the current DspTap main. This was the stalest pin in the family, eleven commits behind, predating tap::dsp::yin, psola and pvoc as well as the shared FIR substrate carried from SampleRateTap -- so this repo was compiling a DspTap that had none of the primitives the library has since grown. Four of the eleven are infrastructure (TapHouse drift pin, SessionStart hook, CLAUDE.md, PR template). The rest add yin, psola, pvoc, the FIR substrate (kaiser.h, sample_traits.h, fir_kernels.h, quantize.h, analysis/) and dot_row_reversed, plus pvoc's LPC formant preservation and a sign-conversion fix in DspTap's own kaiser test. Nothing here calls the new headers -- this repo reaches into tap::dsp for the real FFT, which is unchanged across the range -- so the bump is functionally a no-op. It matters because AmbiTap-Max and AmbiTap-Pd both pin this repo, so drift here compounds two levels down. Pinned to a commit on DspTap's main rather than any in-flight branch, per the release flow: consumer pins must reference a tree that stays reachable after branch cleanup. Verified: configure and build clean with zero compile errors, ctest 156/156 passing in Release. Reaching that took a detour worth recording. This container cannot configure this repo at ANY pin: tests/CMakeLists.txt fetches googletest as a URL tarball, and the agent proxy refuses that download (status_code 22), so FetchContent fails before any of this repo's code is touched. FIND_PACKAGE_ARGS cannot rescue it because no system GTest is installed. The sibling repos are unaffected because they fetch googletest via GIT_REPOSITORY/GIT_TAG, which the proxy allows. The build above was therefore done with -DFETCHCONTENT_SOURCE_DIR_ GOOGLETEST pointed at a local v1.15.2 clone; the failure was environmental and pre-existing, not a consequence of this bump. Checked before bumping: across the whole range every change under DspTap's include/ is an ADDITION -- nine new headers, none modified or deleted -- the exported targets are identical at both ends (tap_dsp_fft, tap::dsp_fft, tap_dsp, tap::dsp, tap_dsp_warnings), and there is no consumer-facing CMake change. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JhhQ93r2E1QTnCx46YfX8j
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What this changes
Refreshes
submodules/dsptapfrom9cbfbcato28a34a1(current DspTapmain) — eleven commits, the stalest pin in the family.The old pin predates
tap::dsp::yin,psolaandpvocentirely, as well as the shared FIR substrate carried from SampleRateTap — so this repo was compiling a DspTap that had none of the primitives the library has since grown. Four of the eleven are infrastructure; the rest add those primitives, the substrate (kaiser.h,sample_traits.h,fir_kernels.h,quantize.h,analysis/),dot_row_reversed, and pvoc's LPC formant preservation.Why
Nothing here calls the new headers — this repo reaches into
tap::dspfor the real FFT, unchanged across the range — so the bump is functionally a no-op. It matters because AmbiTap-Max and AmbiTap-Pd both pin this repo, so drift here compounds two levels down.Verification
Configure and build clean, zero compile errors, ctest 156/156 passing in Release.
Checked before bumping:
include/across the range is an addition — 9 new headers, none modified or deletedtap_dsp_fft,tap::dsp_fft,tap_dsp,tap::dsp,tap_dsp_warningstests/test_kaiser.cpp, not a shipped headerNotes for the reviewer
A build-environment finding worth knowing, independent of this PR. This container cannot configure this repo at any pin:
tests/CMakeLists.txtfetches googletest as aURLtarball, and the agent proxy refuses that download (status_code: 22), so FetchContent fails before any of this repo's code is touched.FIND_PACKAGE_ARGS NAMES GTestcan't rescue it because no system GTest is installed.Its siblings are unaffected because they fetch googletest via
GIT_REPOSITORY+GIT_TAG, which the proxy allows. My first run therefore looked like the bump had broken configure — it hadn't; the failure is environmental and pre-existing. The verification above was done with-DFETCHCONTENT_SOURCE_DIR_GOOGLETESTpointed at a local v1.15.2 clone.Not proposing a change here, since your CI downloads it fine — but switching to the
GIT_REPOSITORYform would make this repo buildable in proxied/offline environments like the sibling repos already are. Your call.Pinned to a commit on DspTap's
mainrather than any in-flight branch, so the pin stays reachable after branch cleanup — and independent of tap/DspTap#8.Part of a four-repo sweep. MuTap is deliberately excluded: also 11 commits behind, but its macOS CI is red from tap/MuTap#31 and a dsptap bump is one of that issue's candidate fixes, so it belongs there rather than in a routine refresh where a still-red CI would be ambiguous.
Generated by Claude Code