settledSweep

settledSweep(program, points, options?): readonly SettledRender[]

Defined in: packages/runtime/src/settle.ts:1018

Settle a program once, then measure it at each control setting in turn on the same runtime.

Why this and not a settle-point cache. The obvious saving is to remember each packet’s settle time and skip the search, but measurement says the search is not the cost: a windowed settledRender runs within 3% of a single process() call of the same duration, because findSettled already stops the moment the level holds. What costs is rendering to settle at all, and a fresh runtime pays the full start-up transient every time — charging supplies over ten seconds to move one knob.

Continuing on a runtime that has already settled pays it once:

packet	initial settle	re-settle after a knob move
marshall-jcm800	10 s, 15.9 s wall	1.5 s, 2.36 s — 6.7x cheaper
hiwatt-dr103	9 s, 23.0 s wall	1.5 s, 3.84 s — 6.0x cheaper
orange-rockerverb	1.5 s	1.5 s — 1.0x, already at the floor

The floor is consecutive stable windows, currently 1.5 s, so a packet that settles that fast gains nothing and loses nothing. The gain is concentrated where the expense is.

The cost of the trick, stated rather than hidden: this is order-dependent by construction. A circuit with memory — a latch, a sag-dependent bias, an envelope with a long tail — can land somewhere different depending on which setting preceded it, where independent renders cannot. That is also more physical than restarting, since a real pedal is never power-cycled between knob positions. sweepIsOrderIndependent checks it directly by sweeping forwards and backwards, and a caller measuring a latching circuit should use settledRender per point instead.

Parameters

program

Program

points

readonly readonly readonly [string, number][][]

options?

SettledRenderOptions = {}

Returns

readonly SettledRender[]