AudioGraphSettings interface

Signature:

export interface AudioGraphSettings<Pins extends string = "audio"> extends ProcessorNodeSettings<AudioGraphNode<Pins>>

Extends: ProcessorNodeSettings<AudioGraphNode<Pins>>

Properties

Property Type Description

Property	Type	Description
build	(graph: AudioGraphBuilder) ⇒ AudioNode \| Record<string, AudioGraphOutputSpec>	Build the processing graph and declare its output(s). Return a single node for one output (which inherits the source’s stream key), or a record of `renditionName → output` for multiple independently-subscribable outputs — each emits a stream whose key carries that renditionName, so downstream subscribes to a specific one by rendition. Outputs may have different channel layouts, and each may pin analysis-tap readings into its qualityMetrics (the `{ node, measurements }` form).
onMeasurement?	(measurement: AudioGraphMeasurement) ⇒ void	(Optional) Called for every measurement an analysis tap (e.g. `rms`) emits.
onParamsApplied?	(update: { nodeIndex: number; params: Record<string, number>; transitionMs?: number; }) ⇒ void	(Optional) Called with every runtime parameter update as the server applies it (the param echo) — relay these to your own UI clients to keep a multi-operator surface in sync without tracking state yourself. `nodeIndex` matches the wire indices `getGraph()` reports.
sources?	Pins[]	(Optional) Multi-source mode: named input pins, one per graph source, in wire-source order — `inputs[k]` in the builder is the stream subscribed to pin `sources[k]` (via with audioToPin()). Omit for a single-input graph (plain `subscribe`). Sources are co-timed by sample count from each one’s first frame — start them together (no PTS-based sync yet).
threads?	number	(Optional) Engine worker threads for a MULTI-SOURCE graph. 1 (the default) runs the engine exactly as it always has, single-threaded. Above 1, the engine spreads the graph’s independent work across that many threads: a wide console’s channel strips are independent of one another, as are its programme sums, so they can run at the same time. Audio and measurements are bit-identical either way — only the thread that computes a given strip changes. Raise this for ONE large graph on a host that is not already busy with other workflows. Norsk already runs separate media nodes in parallel, so on a loaded server these workers only compete with that; and a narrow graph (a single chain of effects) has no independent work to spread, so the setting does nothing for it.

build

(graph: AudioGraphBuilder) ⇒ AudioNode | Record<string, AudioGraphOutputSpec>

Build the processing graph and declare its output(s). Return a single node for one output (which inherits the source’s stream key), or a record of renditionName → output for multiple independently-subscribable outputs — each emits a stream whose key carries that renditionName, so downstream subscribes to a specific one by rendition. Outputs may have different channel layouts, and each may pin analysis-tap readings into its qualityMetrics (the { node, measurements } form).

onMeasurement?

(measurement: AudioGraphMeasurement) ⇒ void

(Optional) Called for every measurement an analysis tap (e.g. rms) emits.

onParamsApplied?

(update: { nodeIndex: number; params: Record<string, number>; transitionMs?: number; }) ⇒ void

(Optional) Called with every runtime parameter update as the server applies it (the param echo) — relay these to your own UI clients to keep a multi-operator surface in sync without tracking state yourself. nodeIndex matches the wire indices getGraph() reports.

sources?

Pins[]

(Optional) Multi-source mode: named input pins, one per graph source, in wire-source order — inputs[k] in the builder is the stream subscribed to pin sources[k] (via with audioToPin()). Omit for a single-input graph (plain subscribe). Sources are co-timed by sample count from each one’s first frame — start them together (no PTS-based sync yet).

threads?

number

(Optional) Engine worker threads for a MULTI-SOURCE graph. 1 (the default) runs the engine exactly as it always has, single-threaded.

Above 1, the engine spreads the graph’s independent work across that many threads: a wide console’s channel strips are independent of one another, as are its programme sums, so they can run at the same time. Audio and measurements are bit-identical either way — only the thread that computes a given strip changes.

Raise this for ONE large graph on a host that is not already busy with other workflows. Norsk already runs separate media nodes in parallel, so on a loaded server these workers only compete with that; and a narrow graph (a single chain of effects) has no independent work to spread, so the setting does nothing for it.