Performance and limits

Audity runs a compiled program on the audio thread, block by block. This page lists the hard limits that program lives inside and the choices that decide cost.

Fixed limits

These are compile-time and runtime caps built into the engine.

Limit	Value	What it bounds
Nodes per program	256	Nodes in one compiled Sound Graph (Sub Graphs are inlined into this count).
Voices per Wave Player	8	Overlapping voices before the oldest is stolen.
Release voices per player	8	Extra voices reserved for stealing, release fades, and tails that begin at Tail Start.
Triggers per block	8	Trigger events processed on one node per audio block.
Channels	8	Maximum audio width (up to 7.1).
Variadic pins	2 to 8	Inputs/outputs on Mixer, Split, Join, routers, and similar.
Array member length	8	Elements in a Float array interface member.
Resident banks	64	Runtime Sample Set banks loaded at once.
Transports	16	Named musical grids active at once.
Pitch range	+/-96 semitones	Hard clamp on total voice pitch.

Voices

Each Wave Player owns a pool of voices. Its Max Voices setting (1 to 8) caps how many can sound at once; a new trigger past the cap steals the oldest voice with a short declick fade. Cut voice mode uses a single voice and restarts it on each trigger; Poly overlaps them.

A Wave Player fed a Streamed sample is forced to a single Cut voice, because a streamed clip plays through one generator instance.

The practical voice budget for a graph is the sum of its players’ caps. Keep Max Voices only as high as the sound needs; a footstep player rarely needs more than 2 or 3.

Source tiers

A Sample’s Source Mode decides how its audio is stored, which trades memory against features. Auto (the default) chooses per clip.

• In-Memory - the clip is decoded to PCM up front and held in memory. Cheapest per-voice CPU, sample-exact triggering, full loop and crossfade support. Costs the decompressed size of the clip in RAM. Best for short, frequent sounds.
• Streamed - the clip plays through its own generator, resampled for pitch. No decoded copy in memory, but whole-clip looping only and one voice. A couple of instances per clip are pre-stocked so triggers are still usually immediate. Best for long one-shots and music.
• Paged - PCM is paged on demand from a Decompress-On-Load clip. Full In-Memory features (seek, region loops, crossfades) without holding the whole clip decoded. Auto uses this for readable clips longer than about 10 seconds.

Batching

A Batch Group caps how many members play at once and collapses dense trigger bursts. It is pure main-thread policy: it decides whether a Play happens, it does not add DSP to the graph.

Configure on the group asset:

• Max Instances - how many members may sound at once (and how many triggers fit the coalesce window).
• Coalesce Window (seconds) - triggers within this window count as one burst.
• Radius - only members within this distance of each other count together (0 = global).
• Overflow - what a request over the cap does: Play Composite (stop the members and play one composite graph at their centroid), Reject New, Steal Oldest, or Steal Farthest.
• Composite Graph - the Sound Graph played once at the members’ centroid when a burst overflows under Play Composite. This is the “one big impact instead of forty pings” sound; author it like any graph.
• Intensity Parameter - the name of a Float member on that composite graph that receives the count of coalesced triggers. Wire it (through a Parameter In into a gain or a Curve) so a denser burst plays a louder or bigger composite - the collapse carries its own intensity.
• Cooldown (seconds) - after the composite fires, further triggers near it are swallowed for this long, so a sustained shower does not retrigger the composite every frame.
• Steal Fade (seconds) - the fade-out applied to members that are stopped by stealing or by the composite swap, so the collapse does not click.

Use it for things that spawn in swarms (glass shards, shell casings, impacts): one window-break instead of forty shard pings.

What scales cost

• Number of playing instances - each is its own program render. Batch groups bound this for swarms.
• Voices per instance - each active voice is resampled and mixed.
• Node count and node type - filters and per-sample DSP cost more than block- rate control nodes; the Float/Trigger side of a graph is cheap.
• In-Memory footprint - decoded PCM held for In-Memory-tier content.
• Paged pool residency - each paged store keeps a fixed pool of resident pages sized from the voices that can hold it: a pinned first page plus a current and next page for every voice on every Wave Player that can select the store, release tails included. Roughly 0.5 MB per resident stereo page, so a default player holds ~16.5 MB per paged store. This is deliberate - the pool is sized so playback can never starve - and Max Voices is the lever: a 1-voice music player needs (and gets) a far smaller pool. The Wave Player node shows its estimate in-graph, Help > Audity > Memory Report breaks down every graph, and the profiler module’s Audity Paged Pool counter shows the live total.

Control values (Float wires) update once per block, not per sample, so a graph heavy in modulation and logic is inexpensive next to its audio path.