ChainRuntime
Defined in: packages/runtime/src/chain.ts:51
Constructors
Section titled “Constructors”Constructor
Section titled “Constructor”new ChainRuntime(
slots):ChainRuntime
Defined in: packages/runtime/src/chain.ts:57
Parameters
Section titled “Parameters”readonly ChainSlot[]
Returns
Section titled “Returns”ChainRuntime
Accessors
Section titled “Accessors”length
Section titled “length”Get Signature
Section titled “Get Signature”get length():
number
Defined in: packages/runtime/src/chain.ts:71
How many slots this chain has.
Returns
Section titled “Returns”number
Methods
Section titled “Methods”prepare()
Section titled “prepare()”prepare(
sampleRate,options?):void
Defined in: packages/runtime/src/chain.ts:81
Gates the whole chain once (see this module’s header), then prepares every slot,
ungated, at the same rate and iteration cap. A slot’s own refusal — an operator or
DSP model this runtime cannot execute — is rethrown naming its slot, since
ReferenceRuntime’s RuntimeError cannot know which slot it ran in.
Parameters
Section titled “Parameters”sampleRate
Section titled “sampleRate”number
options?
Section titled “options?”maxNewtonIterations?
Section titled “maxNewtonIterations?”number
realtimeBudget?
Section titled “realtimeBudget?”Returns
Section titled “Returns”void
process()
Section titled “process()”process(
input):Float64Array
Defined in: packages/runtime/src/chain.ts:148
Slot 0 runs on input; its output buffer becomes slot 1’s input, and so on — the
last slot’s output is the chain’s output.
Whole buffers pass between slots rather than sample-by-sample calls between them.
That is safe, not merely convenient: this is a feedforward chain (no slot reads a
later slot’s output), ReferenceRuntime.process has no lookahead — each sample is a
causal function of that slot’s own past reactive state and the sample handed to it —
so slot 1 sees the identical sample sequence in the identical order whether the chain
hands it one sample at a time or the whole buffer at once. Each slot still advances
its own sample-by-sample loop internally exactly as it always has.
Allocates one Float64Array per slot per call (each ReferenceRuntime.process call
allocates its own output buffer) — for a worklet driven at a small quantum this is an
allocation on the audio thread every callback, once per slot in the chain. Left as is:
reusing scratch buffers across slots is a separate change, noted rather than made here.
Parameters
Section titled “Parameters”Float64Array
Returns
Section titled “Returns”Float64Array
setControl()
Section titled “setControl()”setControl(
slot,id,position):void
Defined in: packages/runtime/src/chain.ts:180
Addresses a control by (slot, id). Slot index is the only disambiguator: two identical
pedals in the chain declare the same control ids, but each slot owns an independent
ReferenceRuntime with its own control-position map, so the shared id never collides
with the other slot’s.
Parameters
Section titled “Parameters”number
string
position
Section titled “position”number
Returns
Section titled “Returns”void
telemetry()
Section titled “telemetry()”telemetry(): readonly
ChainSlotTelemetry[]
Defined in: packages/runtime/src/chain.ts:206
Every slot’s own telemetry, labelled by position — never blended into one set of
totals. A chain’s samples/heldSamples/etc. are per-slot facts (a nonlinear block
failing to converge in slot 2 says nothing about slot 0), so summing or averaging them
would silently under-report whichever slot is actually struggling; see this module’s
header and RuntimeTelemetry in reference-runtime.ts.
Returns
Section titled “Returns”readonly ChainSlotTelemetry[]