@maruaudio/dsp/processors/serial-effect-stack schedules changes to a chain of one to six serial effect slots: their order, an opaque type tag per slot and an active mask. A change fades the wet path out over 256 frames, commits the new snapshot at the dry boundary, waits while the caller clears any slots the change invalidated, then fades back in over 256 frames. The scheduler owns no effect, buffer, callback or registry; the caller keeps its effects and dispatches them statically, reading order, tags and activeMask.

const state = createSerialEffectStackState(6, buffers) // six Int32Array(6)
requestSerialEffectStack(state, order, tags, activeMask, invalidateMask)
const wet = serialEffectStackProcessesWet(state) ? runSlots(x) : x // per frame
const g = serialEffectStackWetGain(state) // y = x * (1 - g) + wet * g
advanceSerialEffectStackFrame(state)

Lifecycle

createSerialEffectStackState(slotCount, buffers) takes six caller-owned Int32Arrays whose length must equal slotCount (1 to 6); a wrong shape gives an inert state on which every call fails closed. Then requestSerialEffectStack → per frame serialEffectStackWetGain, advanceSerialEffectStackFrame → takeSerialEffectStackCommit (the committed revision, consumed once) → during a clear, serialEffectStackClearMask, serialEffectStackClearStoreBudget (256 scalar stores per frame) and acknowledgeSerialEffectStackClear(revision, mask) → resetSerialEffectStack. A request returns REJECTED, SETTLED (no change), STARTED or QUEUED. Reset restores the identity order, zero tags and an empty mask, cancels both snapshots and keeps the revision counter rising. Nothing allocates.

When to use it

A multi-effect rack whose player reorders, swaps or bypasses effects while audio runs, and whose effects keep their own history. A pure reorder carries each slot's state through the transition; only slots in the invalidate mask are cleared. @maru/processors-multi-effect-chain builds on it.

Limits

• Advance once per input frame: each fade has exactly 256 frames, endpoints included, so block partitioning does not change timing.
• One edit in flight, one pending: requests during a transition coalesce to the latest snapshot and never restart or extend the current fade.
• An order must be a permutation of the slots; masks must be integers inside the slot mask, or the request is rejected without consuming a revision.
• A clear acknowledgement must name the committed revision and a subset of the clear mask, so a stale one cannot advance a later edit. Wet gain is f32-rounded; the dry/wet equation belongs to the caller.