StringFlux Decision Log: Oversampling Without Audio-Thread Instability

Problem

StringFlux needed selectable oversampling (1x/2x/4x) to improve high-frequency behavior in the wet path.
The naive implementation risked glitches and instability by rebuilding oversampling state directly in time-critical processing.

Constraint Set

• audio callback path must remain real-time safe
• oversampling changes must not corrupt processing state
• behavior has to remain predictable under host-driven parameter updates
• dry path and meters must stay at host rate for coherence

Decision

I moved oversampling reconfiguration out of the immediate audio processing path.
Configuration requests are queued and applied only at safe boundaries, not mid-callback mutation points.

Alternatives Considered

Immediate in-callback rebuild

Pros:

• conceptually simple
• updates feel immediate

Cons:

• unacceptable risk of callback-time instability
• harder to reason about state continuity

Deferred safe-point application (chosen)

Pros:

• lower real-time risk
• cleaner state transitions
• easier to audit and test

Cons:

• slightly more implementation complexity
• one extra layer of state orchestration

Implementation Notes

• wet path: oversampled processing stages
• dry path: host-rate passthrough
• transition strategy: queued setting changes, applied at controlled points
• verification focus: transition correctness under rapid mode changes and active playback

Outcome Signal (Technical)

StringFlux now supports safe 1x/2x/4x oversampling transitions without rebuilding oversampling state directly on the audio thread. This reduced instability risk while preserving expected routing and scheduler behavior.

Next Validation Targets

• stress-test mode switching under dense grain scheduling
• compare artifact profile between oversampling modes on transient-rich material
• add repeatable test harness scenarios for transition regressions