Skip to content

Replace driver_type filter with Sd-based frequency capability estimate#71

Merged
timini merged 1 commit intomainfrom
feat/sd-based-prescreen-filter
Mar 1, 2026
Merged

Replace driver_type filter with Sd-based frequency capability estimate#71
timini merged 1 commit intomainfrom
feat/sd-based-prescreen-filter

Conversation

@timini
Copy link
Owner

@timini timini commented Mar 1, 2026

Summary

  • Replace the blanket driver_type string filter in prescreen that excluded all cone drivers when target_f_high > 2kHz
  • New filter computes pistonic beaming frequency from Sd (f_piston = c / (2π·√(Sd/π))) and multiplies by a configurable horn_load_factor (default 10×) to estimate horn-loaded upper frequency limit
  • Adds --horn-load-factor CLI argument for tuning the extension factor
  • 6" and 8" cone mids now correctly pass for mid-horn applications (250–6.5 kHz), while 10"+ woofers are still rejected

Test plan

  • All 12 prescreen unit tests pass (updated for new physics-based filter)
  • Run prescreen CLI with 250–6500 Hz target, verify 6"/8" cone mids + compression drivers pass
  • Run prescreen CLI with 40–500 Hz bass target, verify large cone drivers pass

🤖 Generated with Claude Code

…stimate

The prescreen driver_type filter blanket-excluded all cone drivers when
target_f_high > 2kHz, preventing cone midrange drivers (6", 8") from
being selected for mid-horn applications. Replace with a physics-based
check: compute pistonic beaming frequency from Sd and multiply by a
configurable horn-loading extension factor (default 10x).

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
@timini timini merged commit e9d7d4b into main Mar 1, 2026
7 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant