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 at safe boundaries so oversampling state never changes inside the audio callback.

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

Where It Stands

StringFlux now supports safe 1x/2x/4x oversampling transitions without rebuilding state directly on the audio thread. This eliminated the glitches I was hitting during rapid mode changes and kept the routing and scheduler behavior predictable.

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

From Effect Idea to Instrument Direction

StringFlux started as a granular delay concept, but development pushed it toward a more specific goal: a string-focused, transient-aware texture instrument that expands one performance into layered material while keeping playable response.

Recent progress has been less about adding surface-level features and more about stabilizing the engine: tighter DSP behavior, clearer timing/feedback flow, and more predictable state and preset behavior. One difficult stretch was restructuring processing flow to add oversampling safely without breaking the existing signal path. That refactor forced better separation in the engine and made behavior less fragile.

The current direction remains disciplined scope over feature sprawl. The goal is a single playable grain voice across bands: one engine you can lean on in a mix instead of a stack of unrelated stompboxes.