Add configurable feedback high-pass cutoff with smoothing and WASM bindings

[ovelhaaa]

Motivation

• Provide a user-controllable HPF cutoff for the feedback path so feedback tonal balance can be musically tuned instead of fixed to a constant.
• Smooth and atomically stage the new parameter to avoid zipper/noise artifacts and keep MCU-friendly cadence for coefficient updates.
• Make the parameter available through the C API and WASM UI so web/embedded frontends can control the feedback HPF.

Description

• Added a public core setter OrbitDelayCore::setFeedbackHighpassHz(float) and stored state feedbackHighpassHz_, pending atomic pendingFeedbackHighpassHz_ and smoother feedbackHighpassHzSm_ in core/include/orbit_delay_core.h.
• Read and clamp pending values in applyPendingParamsIfNeeded() and mark smoothed targets dirty so updateSmoothedTargetsIfDirty() and advanceSmoothers() drive the smoother; use the smoother output in maybeApplyHighpassCutoff() so runtime HPF updates use the smoothed target (clamped to musical bounds and Nyquist).
• Exposed C API orbit_set_feedback_highpass_hz() and WASM bridge function orbit_wasm_set_feedback_highpass_hz() and added the function to Emscripten exported list in targets/wasm/CMakeLists.txt.
• Wired the WASM UI binding to send feedbackHighpassHz via targets/wasm/js/ui.js to the new WASM bridge function.

Testing

• Verified symbol wiring and presence across core and WASM targets using rg searches for setFeedbackHighpassHz, pendingFeedbackHighpassHz_, orbit_set_feedback_highpass_hz and orbit_wasm_set_feedback_highpass_hz, which succeeded.
• Confirmed the new WASM export name appears in targets/wasm/CMakeLists.txt and the UI binding feedbackHighpassHz is present in targets/wasm/js/ui.js via automated search, which succeeded.

---

Codex Task

[coderabbitai]

Warning

Review limit reached

@ovelhaaa, we couldn't start this review because you've reached your PR review rate limit.

More reviews will be available in 1 minute and 9 seconds. Learn how PR review limits work.

Your organization has run out of usage credits. Purchase more in the billing tab.

⌛ How to resolve this issue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available.

Please see our Fair Usage Limits Policy for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: b4e4c187-eac4-45a2-a0fe-95b3713a31d6

📥 Commits

Reviewing files that changed from the base of the PR and between 82c58e2 and 5352087.

📒 Files selected for processing (7)

• core/include/orbit_delay_c_api.h
• core/include/orbit_delay_core.h
• core/src/orbit_delay_c_api.cpp
• core/src/orbit_delay_core.cpp
• targets/wasm/CMakeLists.txt
• targets/wasm/js/ui.js
• targets/wasm/orbit_delay_wasm.cpp

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch codex/add-highpass-cutoff-parameter-to-feedback

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[gemini-code-assist]

Code Review

This pull request introduces a configurable highpass filter cutoff frequency (feedbackHighpassHz) for the feedback loop in the orbit delay effect. It exposes the parameter through the C API, WASM bindings, and UI controls, while implementing parameter smoothing and clamping within the core engine. A critical thread-safety issue was identified in setFeedbackHighpassHz, where reading the non-atomic feedbackHighpassHz_ member variable concurrently with audio thread writes causes a data race. It is recommended to use the atomic pendingFeedbackHighpassHz_ as the fallback value instead.

[gemini-code-assist]

Thread Safety / Data Race Issue

There is a potential data race on feedbackHighpassHz_. The function setFeedbackHighpassHz is called from the control/UI thread, but it reads feedbackHighpassHz_ (a non-atomic member variable) as a fallback value for sanitizeFinite. Meanwhile, the audio thread writes to feedbackHighpassHz_ in applyPendingParamsIfNeeded() on every processing block.

Reading a non-atomic variable that is concurrently written to by another thread is undefined behavior in C++.

Solution

Instead of falling back to the non-atomic feedbackHighpassHz_, you can safely fall back to the atomic pendingFeedbackHighpassHz_.load(std::memory_order_relaxed). This avoids the data race entirely and ensures thread safety.

Suggested change

	void OrbitDelayCore::setFeedbackHighpassHz(float value) {
	pendingFeedbackHighpassHz_.store(clampf(sanitizeFinite(value, feedbackHighpassHz_), kMinFeedbackHighpassHz, kMaxFeedbackHighpassHz),
	std::memory_order_relaxed);
	pendingParamVersion_.fetch_add(1u, std::memory_order_release);
	}
	void OrbitDelayCore::setFeedbackHighpassHz(float value) {
	const float fallback = pendingFeedbackHighpassHz_.load(std::memory_order_relaxed);
	pendingFeedbackHighpassHz_.store(clampf(sanitizeFinite(value, fallback), kMinFeedbackHighpassHz, kMaxFeedbackHighpassHz),
	std::memory_order_relaxed);
	pendingParamVersion_.fetch_add(1u, std::memory_order_release);
	}