CamillaFIR v2.5.0 - Automated Mixed Phase FIR Generator (Python/WebUI)

[Daverz]

I ran a correction, and it came out with a noticeable channel imbalance (e.g. non-centered vocal in Bird on a Wire). I suggest adding an SPL alignment feature the way OCA uses it (adjust to average between 500 to 2000 Hz. I used 1/24 octave smoothing.)

 

[VilhoValittu]

I ran a correction, and it came out with a noticeable channel imbalance (e.g. non-centered vocal in Bird on a Wire). I suggest adding an SPL alignment feature the way OCA uses it (adjust to average between 500 to 2000 Hz. I used 1/24 octave smoothing.)

Hi Daverz, thanks for the feedback.
In v2.8.7 ( https://github.com/VilhoValittu/CamillaFIR/releases/ ) ,CamillaFIR basically assumes that the left/right channel balance in the system is already in good shape. The idea is not to fix hardware or upstream gain issues, but to work from measurements that are already properly balanced.
If a channel imbalance becomes noticeable after correction (for example, vocals no longer sitting in the center), it usually means there was a level difference in the original measurements. In those cases, turning on stereo_link should take care of it by keeping a shared reference between the channels and avoiding relative level offsets during the correction process.
The SPL alignment idea itself makes sense, and it’s something that could be looked at later as an optional feature. For now, CamillaFIR is trying to stay transparent and predictable rather than applying automatic channel-level adjustments.

 

[alanca3]

What is your typical workflow regarding measurements? I typically take a few shots around the listening area and perform a scalar average, though this doesn’t preserve timing information. Would a time aligned vector average suffice, or is this designed for individual measurements only?

 

[VilhoValittu]

What is your typical workflow regarding measurements? I typically take a few shots around the listening area and perform a scalar average, though this doesn’t preserve timing information. Would a time aligned vector average suffice, or is this designed for individual measurements only?

I personally measure only at the MLP (main listening position), but I take several measurements there. Then I remove the worst one and also the “best” one if it clearly stands out from the rest.
After that, I create a time-aligned vector average from the remaining measurements.
I don’t use scalar averaging because it loses timing information. If averaging is needed, a time-aligned vector average is much better.
In general, CamillaFIR tries to create the best possible filter based on the data it is given. The best measurement method is ultimately the one that gives you the most consistent and convincing results in your own system.

 

[alanca3]

I personally measure only at the MLP (main listening position), but I take several measurements there. Then I remove the worst one and also the “best” one if it clearly stands out from the rest.
After that, I create a time-aligned vector average from the remaining measurements.
I don’t use scalar averaging because it loses timing information. If averaging is needed, a time-aligned vector average is much better.
In general, CamillaFIR tries to create the best possible filter based on the data it is given. The best measurement method is ultimately the one that gives you the most consistent and convincing results in your own system.

Thanks!

 

[VilhoValittu]

CamillaFIR 3.4.2 – Automatic Mode Refinement Update

This update focuses entirely on improving the behavior and stability of Automatic Mode.
No UI changes, no cosmetic additions — just search logic and decision model refinements.

The goal was simple: reduce “lucky” outliers and make the optimization more robust and repeatable.

---

### 1. Two-Phase Optimization with Plateau Detection

Automatic Mode now runs in two stages:

• Phase 1: broad parameter exploration
• Phase 2: refinement around the best-performing presets

If no improvement is detected for a defined number of rounds, the search automatically advances (or stops), instead of blindly consuming trials.

This reduces unnecessary runs and improves convergence consistency.

---

### 2. Target Curve Selection is Now Trial-Based

Built-in house curves (Harman variants, BK series, Studio, Cinema, Flat, etc.) are no longer selected purely by static curve matching.

Process now:

1. Pre-rank curves against the measured response
2. Select Top-N candidates
3. Run actual optimization trials for each
4. Choose winner based on full DSP scoring

Additionally, if a “milder” adjacent curve performs nearly the same (within defined rank and RMS tolerance), the algorithm prefers the milder option to avoid unnecessary LF emphasis.

This significantly reduces over-aggressive curve selection.

---

### 3. Measurement-Based Target Caching

If the same measurement is used again:

• Previously selected best target curve is reused
• Best preset is injected as search seed
• Optimization begins near known optimum

This improves repeatability and reduces warm-up variance between runs.

---

### 4. Improved LF (-6 dB) Estimation

The low-frequency extension estimate now:

• Uses smoothing
• Applies envelope tracking (monotonic LF envelope)
• Requires stable consecutive bins before accepting crossing
• Compares L/R and resolves disagreement conservatively

This avoids false early -6 dB detection caused by SBIR dips or sparse LF bins.

Effect: more realistic mag_c_min determination.

---

### 5. Revised Ranking Model

The scoring function was rebalanced to prevent single-metric domination.

Rank now considers:

• Acoustic score (with fallback path if AI score unavailable)
• Soft-knee net boost penalty (no hard 5 dB cliff anymore)
• DSP quality penalties (GD gradient, ripple, boundary artifacts)
• Pre-ringing / pre-energy metrics
• Reflection severity weighting
• L/R symmetry
• Excursion protection behavior

Each penalty has capped contribution to avoid collapse-to-zero behavior.

The net boost penalty now uses a smooth hinge instead of a hard threshold.

---

### 6. Excursion Protection Awareness

Automatic Mode now:

• Prefers presets where excursion protection remains active
• Penalizes LF boost inside excursion-guard region
• Reduces (but does not eliminate) excursion penalty when auto frequency detection is valid

This prevents selection of technically “good looking” filters that are mechanically risky.

---

### 7. Filter-Type Aware Search

Search space adapts depending on filter type:

Mixed phase:
• Optimizes mixed crossover frequency

Linear phase:
• Optimizes phase limit region

All modes respect bass-first logic and smoothing constraints.

---

If anyone wants to test edge cases:

• Strong SBIR null systems
• Large LF drivers with excursion limits

Feedback is welcome.

Disclaimer : AI was used to translate this text Finnish --> English

 

[VilhoValittu]

What’s new in 4.0.3
This version is a significant step forward, especially in automatic optimization, usability, performance, and UI architecture.

Fully matured Automatic Mode
Automatic mode has evolved from a “good starting point” into something much closer to a complete end-to-end solution:
Multi-stage optimization (target preselection → refinement → Pareto selection)
Better handling of difficult rooms (room modes, uneven decay)
More stable and repeatable results across runs
Built-in safety constraints (no more “over-optimizing into nonsense”)
In practice:

You can now trust Auto Mode to produce final-use filters, not just drafts.

Major Automatic Mode speed improvements
Automatic Mode has been significantly optimized:
Faster optimization cycles
More efficient search and pruning
Reduced unnecessary evaluations

Result:
Noticeably shorter run times, especially on complex datasets

Makes iterative workflows much more practical

Smarter DSP decisions (less user babysitting)
Several internal improvements reduce the need for manual tweaking:
Confidence-weighted correction (less correction where measurement is unreliable)
Temporal Decay Control (TDC) integrated more tightly into optimization
Improved bass handling (less boom / less overcorrection)
Better balance between:
flatness
ripple control
total boost
perceived sound quality
Result: more “room-safe” filters without killing dynamics.

Mixed-phase & phase control improvements
More consistent phase behavior in automatic runs
Better low-frequency phase handling
Reduced risk of excessive group delay artifacts
This was one of the weaker areas in early versions — now it’s much more predictable.

Migration to NiceGUI (major UI upgrade)
The UI has been migrated to NiceGUI, which is a significant architectural improvement:
More responsive and modern UI behavior
Better foundation for interactive features (live previews, future drag controls, etc.)
Cleaner separation between UI and DSP logic
Easier to maintain and extend going forward
This is not just a visual change — it enables faster iteration and more advanced UX improvements in future versions.

UI / workflow improvements
On top of the new UI foundation:
Clearer separation between Basic vs Advanced
More meaningful defaults (less need to touch advanced parameters)
Better feedback in results / summaries
Cleaner workflow from measurement → filter
Still technical, but much closer to a “tool” than a parameter playground.

Reproducibility & stability
A big focus in recent versions:
Same input → much more consistent output
Less randomness in optimization outcomes
Improved internal scoring and ranking logic
This matters especially when comparing filters or iterating setups.
What this means in practice
Compared to earlier versions (like 2.x / early 3.x):
Less manual tuning needed
Faster iteration cycles
Fewer “weird” filters
More consistent bass behavior
Better results in imperfect measurement conditions
In many cases, Auto Mode now gets surprisingly close to what you’d manually dial in after multiple iterations.
Positioning vs other solutions
CamillaFIR is still very much a DIY / transparent DSP tool, not a black box.
But with 4.0.3:
It starts to approach the ease-of-use of automated systems
While keeping full control and visibility

Try it
GitHub:

https://github.com/VilhoValittu/CamillaFIR⁠

Latest release: 4.0.3

Feedback welcome
As always, feedback from real systems (especially difficult rooms) is extremely valuable.
If you try it:
share measurements
share results
share what sounds wrong (that’s the most useful)

 

[HenrikEnquist]

I’ve been thinking a bit about the name CamillaFIR. The tool has grown into something really useful, and it’s great to see how far it has come. At the same time, the current name can be a bit confusing for users, since it suggests a direct connection to CamillaDSP even though it’s designed to work with other DSP engines as well.

To avoid that confusion and to help the project stand more clearly on its own, I think it would be beneficial to consider a new name. I’ve seen several users assume it’s one of my projects, and a more neutral name would make its broader scope much clearer.

 

[john61ct]

DidoFIR (ref the Aeneid)

MilenaFIR

MilaFIR

 

[Daverz]

I’ve been thinking a bit about the name CamillaFIR. The tool has grown into something really useful, and it’s great to see how far it has come. At the same time, the current name can be a bit confusing for users, since it suggests a direct connection to CamillaDSP even though it’s designed to work with other DSP engines as well.

To avoid that confusion and to help the project stand more clearly on its own, I think it would be beneficial to consider a new name. I’ve seen several users assume it’s one of my projects, and a more neutral name would make its broader scope much clearer.

AutoFIR?

 

[VilhoValittu]

I’ve been thinking a bit about the name CamillaFIR. The tool has grown into something really useful, and it’s great to see how far it has come. At the same time, the current name can be a bit confusing for users, since it suggests a direct connection to CamillaDSP even though it’s designed to work with other DSP engines as well.

To avoid that confusion and to help the project stand more clearly on its own, I think it would be beneficial to consider a new name. I’ve seen several users assume it’s one of my projects, and a more neutral name would make its broader scope much clearer.

Ofcourse. I will do that.

Vilho

 

[john61ct]

NobleFIR, GrandFIR can grow over 300' tall

 

[VilhoValittu]

CamillaFIR needs new name , vote if interested. Voting ends May 10th 2026

Vilho

 

[HenrikEnquist]

Ofcourse. I will do that.

Vilho

Thank you!

 

[ShadowBoxer]

I have to concur that AutoFir rolls off the (English) tongue a bit more than the other candidates.

 

[john61ct]

Too generic for my taste

 

[HenrikEnquist]

FIRForge?
Coming up with good names is super hard! Does it have to be SomethingFIR? I mean FIR is just finite impulse response, quite generic and for example AutoFIR could just as well be the name of a convolver.

 

[HenrikEnquist]

I noticed this project went closed source a few weeks ago. Any chance you could share the reasons? A bit sad to see, it was a nice open tool for the community.

 

[Julf]

I noticed this project went closed source a few weeks ago. Any chance you could share the reasons? A bit sad to see, it was a nice open tool for the community.

That's a bummer.

 

[VilhoValittu]

FIRForge?
Coming up with good names is super hard! Does it have to be SomethingFIR? I mean FIR is just finite impulse response, quite generic and for example AutoFIR could just as well be the name of a convolver.

No, name doesn't have to include FIR. Maybe somethingEQ would work.

I noticed this project went closed source a few weeks ago. Any chance you could share the reasons? A bit sad to see, it was a nice open tool for the community.

I have been thinking this. My measurement section includes code from closed source.

I will release code-base without measurement code when I deside new name.
Personally I have learned very much from open source code and I'm big fan of it.

Measurement section will be included at releases.