VVVV vs TouchDesigner Architecture

2026-02-22 12:33 UTC gpt-5-2-thinking Open in ChatGPT ↗

Below is a practical “architecture-level” comparison (how each system is structured, evaluates graphs, represents data, and how you extend/deploy it).

Core programming model

vvvv (beta / gamma)

Dataflow patching + “spread” (vectorized) semantics. A single link can carry many values (“slices”) and nodes typically auto-align slice counts (a built-in SIMD-ish feel). citeturn1search1turn1search4turn1search23
Gamma specifically: the language is VL, mixing dataflow + functional + OO concepts, and designed to interop with the .NET ecosystem. citeturn1search21turn1search8
Patch is the program. Composition is done by building subpatches / abstractions (and in gamma: more explicit type/data modeling via VL concepts).

TouchDesigner

Operator (OP) graph where each node is an Operator belonging to a family (TOP/CHOP/SOP/DAT/COMP, etc.), i.e., the data type is strongly implied by which family you’re in. citeturn0search4
Component-centric modularity. “COMP” operators wrap sub-networks and expose inputs/outputs via In/Out OPs—TouchDesigner’s primary encapsulation unit. citeturn0search13
Parameters and exports are first-class: CHOP channels can drive (“export to”) parameters across the graph, which is a core architectural pattern. citeturn0search16

Evaluation / execution model (the “when does it run?” question)

vvvv

Frame-based evaluation with lazy traversal from sinks: each frame, evaluation starts from nodes that “need” results (renderers/writers) and pulls upstream; some nodes avoid evaluating unused branches. citeturn1search2turn0search0
Can incorporate reactive / async building blocks for background calculations and even alternative mainloop patterns (gamma). citeturn0search15

TouchDesigner

Uses “cooking”: operators cook only when needed, not necessarily every node every frame; the engine tracks dirtiness/dependencies. citeturn1search0
Components have a Cooking Flag to disable internal network cooking—useful for performance and controlling evaluation. citeturn1search14

Big contrast: both are demand-driven, but vvvv documentation frames it as frame-based lazy evaluation from sinks, while TouchDesigner formalizes it as cook-on-demand with explicit cook controls/flags and cook-time introspection. citeturn1search2turn1search0turn1search14

Data model differences

vvvv

Primary “collection” abstraction is the Spread (and related collection types), with lots of built-in slice/spread operations. citeturn1search7turn1search4turn1search1
This encourages architectures where “many things” are processed in parallel through the same node chains (one patch expresses N instances).

TouchDesigner

Data types are more explicitly separated by OP families:
- TOP = images/textures (GPU)
- CHOP = time-sampled channels
- SOP = geometry
- DAT = tables/text
- COMP = containers/networks
  (Family concept: citeturn0search4)
Cross-family conversion is done via bridge operators like SOP to CHOP / CHOP to SOP, etc. citeturn0search7turn0search2

Extensibility and “where code fits”

vvvv (gamma)

You can author new nodes by writing C# that VL turns into nodes; integrates naturally with .NET libraries. citeturn0search5turn1search21

TouchDesigner

Python is deeply integrated (many operator types have script variants with cook() callbacks, etc.). citeturn1search22turn1search17turn1search12
You can build Custom Operators in C++ (and they appear as OP families). citeturn0search4

How this shapes “application architecture” in practice

vvvv tends to scale by data-parallelism + reusable graphs: you often build patches that operate over spreads (many instances), and rely on sink-driven frame evaluation. citeturn1search1turn1search2
TouchDesigner tends to scale by typed networks + componentization: you structure projects as COMPs, manage cook boundaries/flags, and move data between typed families (TOP/CHOP/SOP/DAT) with explicit bridging OPs. citeturn0search13turn1search0turn0search2turn0search7

Key documentation links (official / primary)

vvvv

Evaluation model (lazy, frame-based): citeturn1search2
Dataflow basics: citeturn0search17
Spreads & collections: citeturn1search7
Writing nodes in C# (gamma/VL): citeturn0search5
Reactive/async building blocks: citeturn0search15

TouchDesigner

Cooking model: citeturn1search0
Operator families overview: citeturn0search4
Components (encapsulation + I/O): citeturn0search13
CHOP export concept: citeturn0search16
SOP↔CHOP bridge examples: citeturn0search7turn0search2

If you tell me whether you mean vvvv beta or vvvv gamma/VL for your current work (or both), I can tailor the comparison to practical project structure patterns (render loop, state, performance boundaries, deployment) for that specific version.

If the non-negotiables are “works inside Unity,” “interoperable with all Unity systems,” and targets creative coders + large live AV, I’d bias toward a TouchDesigner-style “typed operator graph + cooking (demand-driven) + component encapsulation” as the primary architecture — and then deliberately graft in vvvv’s spread/vectorization as a data model feature rather than as the whole execution model.

Why TD-style is the preferable base for Unity specifically

Unity already has strongly-typed subsystems with clear boundaries and lifecycles:

Rendering (SRP, RenderGraph, textures/buffers/materials)
Animation (Playables)
Audio (DSP graph-ish constraints, audio thread)
Physics
UI
Entities/DOTS + Jobs + Burst
Timeline / time sources
Serialization / assets

A TD-like operator family approach maps cleanly onto Unity because you can create first-class “domains” that align with Unity primitives:

GPU image/texture graph (TOP-like) → RenderTextures, GraphicsBuffers, compute kernels
Time-sampled signals graph (CHOP-like) → animation curves, audio control-rate signals, envelope followers
Geometry graph (SOP-like) → Mesh, VFX Graph style buffers
Text/table graph (DAT-like) → ScriptableObjects, JSON, tables, OSC/MIDI mappings
Container graph (COMP-like) → Prefabs / Subgraphs / reusable rigs

And the “cook only when needed” mentality is exactly what you want when Unity is already deciding when to render, animate, simulate, etc. You want your graph to participate in Unity’s scheduling, not fight it.

What to steal from vvvv (the “best of both worlds” part)

vvvv’s killer feature for creative coders is the ergonomics of multiplicity:

Make one patch, drive 1 object or 10,000 objects without manually instancing networks.
“Spreads” (vectorized lists) + auto-alignment rules are extremely productive.

So: keep TD-ish typed domains + cook model, but make every operator vectorization-aware:

Any input can be a scalar or a “spread”
Operators define broadcasting rules (like numpy): scalar ⨉ list, list ⨉ list, etc.
Under the hood, compile “spread ops” to Burst jobs (or GPU kernels if the domain is GPU)

That gives you TD’s composable “systems” feel and vvvv’s data-parallel expressiveness.

The biggest problems you’ll hit (in practice)

1) Unity lifecycle + determinism vs. “graph evaluation”

Unity doesn’t have one loop — it has many:

Update / LateUpdate / FixedUpdate
Render loop(s) (SRP)
Audio thread
Playables evaluation
Editor vs Play Mode differences

Hard part: defining when each domain cooks and keeping it deterministic.

If you’re sloppy, creative users will get “it works until it doesn’t” behavior, especially live.

You’ll need: explicit time sources (wall clock, audio clock, timeline time, LTC/MTC) and a routing system so operators know which clock they’re on.

2) Threading constraints (especially audio)

Audio callbacks must be real-time safe: no allocations, no locks, no main-thread calls.
Many Unity APIs are main-thread-only.
GPU work is asynchronous and tricky to synchronize without stalling.

You’ll need: a hard separation:

Control-rate graph (main thread / jobs)
Audio-rate graph (audio thread safe subset)
GPU graph (render thread / command buffers) …and clean bridges between them.

3) Performance and GC pressure

Node graphs in C# can become death-by-a-thousand-cuts:

per-node allocations
boxing/unboxing
virtual dispatch
copying big arrays per connection

You’ll need:

value-based data containers (NativeArray, GraphicsBuffer)
pooled memory + explicit lifetimes
compile graphs to efficient executors (Burst jobs / codegen)
“dirty propagation” so only affected subgraphs run

4) Interoperability with “all Unity systems” is mostly about data ownership

Unity systems expect to own certain things:

Meshes/materials/textures
Animation clips / playable graphs
GameObject hierarchies or Entities
Serialized assets

If your graph owns everything, Unity integration will feel bolted-on. If Unity owns everything, your graph becomes a weak “controller.”

You’ll need a clean ownership model:

Some operators produce assets/buffers
Some operators bind to existing Unity objects (non-owning views)
Some operators author reusable rigs as assets (subgraphs, prefabs, scriptable objects)

5) Editor UX and debugging at scale

Creative coders tolerate rough edges; live AV teams do not. You’ll need:

live probing/scope tools (like CHOP scopes)
GPU texture viewers
“why is this cooking?” introspection
dependency graphs, performance profiling per operator
stable undo/redo and serialization through Unity domain reloads

6) Versioning and portability of graphs

Large productions need:

graph diff/merge in source control
stable GUID-based references
forward/backward compatibility
robust asset import/reimport behavior

This is often harder than the runtime.

My recommended “preferable architecture” in one line

TD-style typed operator/component graph + cook-on-demand + explicit domain boundaries, with vvvv-style spreads/broadcasting as a pervasive data feature, and Burst/Jobs + GPU backends as the primary execution strategy.

If you want, I can sketch a concrete architecture blueprint (core interfaces, data types, scheduling, and how it plugs into SRP/RenderGraph, Playables, DOTS, and audio) at the level of “here are the 10 operator families you start with and how cooking/dirty propagation works.”

Here’s a concrete blueprint you can actually build toward: a Unity-native, TD-ish typed operator/component graph with cook-on-demand, plus vvvv-style spreads/broadcasting, compiled where possible to Burst jobs or GPU command buffers, and with explicit bridges to Unity subsystems.

0) Design goals and non-goals

Goals

Runs inside Unity (Play Mode + Editor tooling).
Interoperable with RenderGraph/SRP, VFX Graph, Playables, Audio, DOTS, Timeline, Input, UI, Net/OSC/MIDI.
Supports live AV: stable timing, external clocks, minimal GC, introspection.
Feels good to creative coders: fast iteration, vectorized data (spreads), scripting escape hatches.

Non-goals (initially)

“One graph to rule everything” across audio-rate + GPU + physics without boundaries.
Full deterministic replay across all Unity subsystems out of the gate.

1) High-level architecture

Core layers

Graph Model (pure data)

Nodes, ports, connections, parameters, subgraphs.
Serializable as ScriptableObjects/assets.

Runtime Graph Instance

Compiled executor(s) + caches.
Maintains “dirty” state, resources, profiling.

Domain Runtimes (typed families)

GPU/Image domain (TOP-like)
Signal domain (CHOP-like)
Geometry domain (SOP-like)
Data/Text domain (DAT-like)
Container domain (COMP-like)
Event domain (triggers/messages)

Unity Bridges

SRP/RenderGraph bridge
Playables bridge
Audio DSP bridge
DOTS bridge
Timeline bridge
Input bridge
External I/O (OSC, MIDI, DMX, NDI/Spout/etc.)

Editor Tooling

Node graph UI (GraphView)
Viewers (texture, scope, mesh)
Cook inspector (“why cooked”, timings)
Debug probes & recorders

2) The “OP family” concept in Unity terms

Make families explicit. Each family has:

Data types (payload)
Scheduler integration (when it can cook)
Resource lifetime strategy
Viewer/debug tools

Suggested families

TOP (GPU Image/Texture)

Payload: TextureHandle (RenderGraph) or RenderTexture/Texture for simpler paths
Execution: command buffer passes, compute, blit, material
Viewer: texture viewer + histogram

CHOP (Signals)

Payload: SignalBuffer (control-rate, fixed timestep optional)
Vectorization: channels × samples, plus per-channel metadata
Viewer: scope/spectrum, record/playback

SOP (Geometry)

Payload: GeometryBuffer (Mesh + attribute streams OR GraphicsBuffer for procedural)
Execution: Burst jobs for CPU geometry, GPU compute for procedural streams
Viewer: mesh viewer + attribute inspector

DAT (Structured Data)

Payload: tables/JSON/text, plus Variant keys
Execution: mostly CPU, caching-heavy
Viewer: table viewer, diff/compare

COMP (Component)

Contains subgraph + exposed interface ports + parameter pages
Equivalent to Prefab-like reusable module

EVT (Event)

Payload: timestamped events / messages / triggers
Think: “bangs” + message buses (OSC/MIDI/DMX) + UI triggers

This mirrors TD, but it’s Unity-first: TOP maps to RenderGraph, CHOP maps to Jobs + Playables parameters, etc.

3) Data model: “spreads” without losing type safety

You want vvvv’s “one patch can drive N things” without everything being untyped lists.

Core container types

Value<T>: scalar
Spread<T>: vector of T (NativeArray-backed when possible)
Field<T>: structured multi-dimensional (optional later)

Broadcasting rules (simple + predictable)

Implement numpy-like broadcasting:

Value<T> + Spread<T> ⇒ Spread<T> (scalar expands)
Spread<T>(n) + Spread<T>(n) ⇒ Spread<T>(n)
Spread<T>(n) + Spread<T>(m):
- If one is 1, broadcast to the other
- Else error (or explicit “ZipLongest” operator)

Key: keep it explicit enough for live systems (no “mystery alignment”), but still productive.

Port types (examples)

CHOP: Spread<float> (single channel multi instances)
CHOP: SignalBuffer (channels × samples)
TOP: TextureHandle
SOP: GeometryBuffer
DAT: Table
EVT: Spread<Event>

4) Execution model: cooking + dirty propagation + schedulers

The principle

No node runs “just because it exists.” It runs because:

a downstream consumer requested it (pull)
or it is a source with a clock that ticks (push / invalidation)

Graph evaluation phases

You will have multiple schedulers, not one:

Frame Scheduler (main thread, per frame)
Fixed Scheduler (FixedUpdate)
Render Scheduler (SRP pass / RenderGraph integration)
Audio Scheduler (audio thread / DSP graph)
External Clock Scheduler (LTC/MTC/NTP, OSC time tags)
Manual (button/trigger)

Each node declares an Execution Domain and Clock:

Domain = TOP, Clock = Render
Domain = CHOP, Clock = Frame or Fixed or Audio
Domain = EVT, Clock = External etc.

Core cooking API

At runtime, everything revolves around a single call shape:

ICookedValue Cook(PortRef output, CookContext ctx);

But internally you’ll compile it to avoid virtual calls in tight loops.

Dirty propagation

Two ways to propagate “needs recompute”:

Pull: “I need this output now; if upstream dirty, cook it”
Push invalidation: parameter change marks dependent nodes dirty

You’ll maintain a dependency graph at compile time:

adjacency lists per node
per-output cache key (frame index, clock time, render pass, etc.)

Caching keys

Cache is not “one size fits all.” Use per-domain cache keys:

Frame-based: frameIndex
Fixed: fixedTick
Render: renderPassId + cameraId
Audio: sampleTime / blockIndex
External: timecode / timestamp

5) Resource & memory ownership (make this explicit early)

Runtime “Resource Registry”

Central place to allocate/pool:

GraphicsBuffer
RenderTexture / RenderGraph transient textures
NativeArray / persistent buffers
Mesh pools
external handles (NDI/Spout textures etc.)

Give each cook a CookScope with lifetime:

Transient (valid for this cook only)
Frame (valid for this frame)
Persistent (until graph destroyed)
External (owned by Unity or external plugin)

This avoids the “who owns this buffer?” nightmare.

6) Interop points with Unity systems

SRP / RenderGraph (TOP domain)

Best path: treat TOP outputs as RenderGraph resources when rendering.

A TOP node contributes a RenderGraph pass.
It declares inputs (textures/buffers) and outputs.

Fallback path (simple): RenderTexture pipeline for non-SRP/legacy.

Bridge nodes

CameraInTOP: imports camera color/depth
TOPToMaterial: binds to material properties
TOPToUI: outputs to RawImage / UI Toolkit texture
ExternalTextureInTOP: Spout/NDI/etc.

Playables (CHOP domain)

Use CHOP to drive:

Animator parameters
PlayableGraph custom mixers
Timeline tracks (via bridge)

Bridge nodes

AnimatorParamsOut
PlayableFloatOut
TimelineTimeIn (clock source)

DOTS (SOP/CHOP domain)

CHOP spreads map well to IJobParallelFor.
SOP geometry can be produced into GraphicsBuffer for Entities Graphics.

Bridge nodes

EntitiesIn (query entities, read components)
EntitiesOut (write components safely, likely deferred)
GraphicsBufferOut for Entities Graphics

Audio (Audio CHOP)

Hard boundary:

audio-thread-safe subset only
preallocated buffers only

Bridge nodes

AudioInCHOP (FFT, envelope follower)
CHOPToAudioParam (control rate → audio param smoothing)
ScriptDSPCHOP (advanced users)

Live AV I/O (EVT/DAT/CHOP)

OSC/MIDI/DMX input → EVT or CHOP
mappings become assets (DAT tables) that drive parameters

Bridge nodes

OSCIn, OSCOut
MIDIIn, MIDIOut
DMXOut
MappingDAT (routes incoming messages to parameter paths)

7) Node authoring model (for creative coders)

Give three tiers:

Pure Graph Nodes

built-in operators (math, mix, filter, resample, etc.)
high performance

Script Nodes (C# + Burst optional)

a “ScriptCHOP / ScriptDAT / ScriptSOP”-like concept
provides strongly-typed inputs/outputs
sandboxed allocations
can be Burst-compiled for CHOP/SOP kernels

Plugin Nodes

native plugins for GPU/video I/O, codecs, capture cards

Key UX feature: hot reload node code without nuking the whole graph state (where possible).

8) Componentization (COMP) and “Unity prefab” alignment

A COMP should feel like:

a Prefab with exposed ports and parameter pages
instanced multiple times in a scene (like subgraphs with overrides)

Implementation detail:

GraphAsset (ScriptableObject): immutable-ish definition
GraphInstance (MonoBehaviour or ScriptableObject runtime): holds state/caches/resources
SubgraphNode references a GraphAsset and creates a nested instance with parameter overrides

9) Debugging, introspection, and live reliability (must-have for AV)

Cook Inspector

For any node/output:

last cook time
average / max over N frames
reason cooked (“input X changed”, “downstream requested”, “clock tick”)
cache hit/miss

Probes

ProbeTOP: thumbnail + pixel readback (optional)
ProbeCHOP: scope, record, export CSV
ProbeSOP: inspect attributes, bounds, draw wireframe

Safety / fallback

budget-based cooking: “don’t exceed X ms per frame” (optional)
graceful degradation: reduce resolution, drop samples, skip non-critical branches

10) Concrete runtime types & interfaces (minimal set)

Graph compilation outputs

CompiledGraph
- NodeExec[] per domain
- dependency lists
- port routing tables
- stable IDs for profiling and serialization

Node runtime contract (conceptually)

Setup() (allocate persistent state)
Invalidate(reason)
Cook(ctx, outValue) (no allocations, uses pools)
Dispose()

Domain runtime

schedules cooks based on clock + requests
provides domain-specific context:
- TOP: RenderGraph builder, cmd buffers, camera
- CHOP: timebase, sample rate, block size
- SOP: mesh pools, attribute layouts
- DAT: string pools, parse caches

11) A simple “end-to-end” example graph (live AV)

Goal: OSC faders + audio input drive a generative mesh and postprocess to LED wall.

OSCIn (EVT) → MappingDAT (DAT) → updates parameters on:
- NoiseCHOP (CHOP)
- AudioInCHOP (CHOP) → Envelope (CHOP)
CHOP signals → MeshDeformSOP (SOP) produces GeometryBuffer
SOP → RenderSOPTOP (TOP) renders into texture
TOP → PostFXTOP (TOP) (bloom, color)
TOP → NDIOutTOP (TOP) or SpoutOutTOP (TOP) or LEDWallOut

This uses each domain where it shines, with bridges that are explicit and debuggable.

12) Biggest “gotchas” to solve early (so the blueprint survives reality)

Time and clocks

Decide how clocks are represented and how nodes choose a clock.
Make “external timecode” a first-class clock.

No-GC cooking

Enforce: no allocations in Cook paths.
Provide pooled temp allocators per cook scope.

Cross-domain synchronization

CHOP driving TOP parameters must be stable and predictable.
Define exactly when parameter sampling happens for render.

RenderGraph integration

If you want “big AV + scalable,” RenderGraph-first is worth it.
But provide an RT fallback for older setups.

Serialization + domain reload

Graph assets must survive domain reload and keep stable IDs.
Runtime state must rebind resources cleanly.

Suggested build order (so you get something usable fast)

CHOP + DAT + EVT (control system + mapping + scripting)
TOP basic (blit/material/compute + viewer)
COMP/subgraphs + parameter pages
Profiling + cook inspector
SOP basic (procedural mesh + GPU buffers)
SRP/RenderGraph deep integration
Audio thread-safe CHOP subset
DOTS bridges
External I/O plugins (NDI/Spout/DMX)

If you want, I can go one notch more concrete and sketch:

a minimal set of C# types (Port<T>, Spread<T>, CookContext, ResourceRegistry, CompiledGraph)
how RenderGraph TOP nodes declare passes
how a CHOP node compiles to IJobParallelFor with broadcasting rules

…and I’ll keep it structured so it turns into an actual code skeleton.

You make it work by not trying to have “one evaluation.” You treat the project as a set of clock domains that exchange data through explicit bridges (with buffering/resampling rules). That’s how TD-style systems stay sane, and it’s also how Unity is already structured (render loop ≠ fixed step ≠ audio thread).

The core idea: clock domains + bridges

1) Every node belongs to exactly one clock domain

Examples:

Frame clock: Update() (control/UI, most CHOP control-rate)
Fixed clock: FixedUpdate() (physics-driven signals)
Render clock: per-camera render (TOP cooking via SRP/RenderGraph)
Audio clock: audio thread blocks (DSP)
External clock: timecode / OSC timetags / NTP-like

A node never “half cooks” on two clocks. If it needs two, it’s actually two nodes with a bridge between them.

2) Nodes cook “when requested,” but the request is scoped to a clock tick

So a cook request always has:

Clock ID (Frame, Render@CameraX, AudioBlock, ExternalTick)
Time in that clock (frame index, render pass id, audio sample time, timecode)
Budget / policy (optional: allow stale? interpolation? drop frames?)

That means your cache keys include the clock tick.

Data exchange rules between clocks

When data flows from one clock domain to another, it must pass through a Bridge Operator that defines exactly one of these behaviors:

A) Hold-last-value (ZOH)

Common for:

CHOP (Frame) → TOP (Render): use the latest control values when rendering.
EVT (External) → CHOP (Frame): process events and keep resulting values until next change.

Bridge: HoldLatest

stores last produced value + timestamp
render reads without forcing upstream to run

B) Interpolate / resample

Common for:

Fixed → Frame: smooth physics signals
Frame → Render: if render runs multiple cameras or variable FPS
Audio → Frame: envelope/FFT at audio rate, downsample to control rate

Bridge: Resample

knows source + dest timebases
can do linear interp, spline, band-limited (audio), etc.

C) Buffer / queue (event streams)

Common for:

External timecode events → Frame processing
MIDI/OSC events → multiple subsystems

Bridge: EventQueue

lock-free ring buffer or double-buffer swap
consumer drains events each tick

D) Latch / snapshot at boundary

Common for:

Frame → RenderGraph pass building: snapshot parameters once per render pass build.
Frame → Audio: snapshot parameter changes and apply with smoothing.

Bridge: LatchAtTick

“sample-and-hold” at a defined boundary (begin render / begin audio block)

Scheduling: who triggers what?

Each clock domain has its own scheduler

FrameScheduler runs once per Unity Update tick.
FixedScheduler runs in FixedUpdate.
RenderScheduler runs during SRP rendering callbacks; creates RenderGraph passes and resolves TOP cooks.
AudioScheduler runs per audio block on audio thread (very restricted).
ExternalScheduler runs when packets/timecode arrive, or a poll tick.

Within a scheduler:

sinks request outputs (e.g., “final TOP for camera”)
the scheduler cooks only nodes in its domain
bridges provide inputs from other domains without cross-thread calls

Important constraint: a scheduler never directly cooks another scheduler’s nodes. That’s the rule that prevents deadlocks and “why did audio trigger rendering?” chaos.

A concrete example

Example: CHOP noise drives a TOP shader, plus audio envelope modulates it

NoiseCHOP (Frame clock)
AudioEnvelopeCHOP (Audio clock)
CombineCHOP (Frame clock) wants both
ShaderTOP (Render clock)

How it works:

Audio clock: AudioEnvelopeCHOP produces envelope at audio block rate → writes to Audio→Frame Resample Bridge.
Frame clock: CombineCHOP reads resampled envelope + noise → produces control values.
Render clock: ShaderTOP reads controls through a Frame→Render Latch at the start of the camera render → uses stable values for the whole render pass.

No render cooking on audio thread, no audio cooking during render.

Graph-level mechanics you’ll implement

1) Clock-aware cache keys

Each output cache is keyed by something like:

(clockId, tickId) where:
- Frame: tickId = frameCount
- Fixed: tickId = fixedStepCount
- Render: tickId = (frameCount, cameraId, passId)
- Audio: tickId = audioBlockIndex (or sampleTime / block)
- External: tickId = timecodeFrame or timestamp bucket

So “is it dirty?” means “is it dirty for this clock tick?”

2) Bridge nodes own the cross-clock state

A bridge is literally the “shared memory boundary”:

double buffers
ring buffers
timestamps
interpolation state
smoothing filters

Everything cross-clock goes through these. That gives you:

debuggability (“what value crossed, when?”)
safety (threading constraints)
predictable latency (one block/frame, etc.)

3) Policies for latency vs accuracy

Every bridge should expose a policy:

Allow stale (render can reuse last frame)
Max latency (drop old events if overloaded)
Interpolation mode
Smoothing (esp. Frame→Audio)
Blocking allowed? (almost always NO outside Editor tools)

For live AV you almost always choose non-blocking + graceful degradation.

Edge cases (where people get burned)

Multiple cameras / multiple render passes

Render clock isn’t “one per frame”; it’s often:

per camera
possibly multiple passes (color, depth, post, XR eyes)

So your Render tickId must include (camera, pass) or you’ll get weird “camera A overwrote camera B’s cached output.”

Editor + Play Mode

In Editor, you can have:

repaint-driven renders
paused time but still rendering UI So clocks must work with “time not advancing” while still allowing cooking in certain domains for editor preview.

Feedback loops across clocks

If you allow a loop like Render→Frame→Render, you must break it with:

a one-tick delay buffer, or
explicit “feedback node” that uses previous tick’s output Otherwise you get infinite recursion or hidden stalls.

The simplest rule-set that scales

If you want a mantra that keeps the system coherent:

One node = one clock.
One scheduler never cooks another scheduler’s nodes.
Cross-clock edges must be bridge operators with explicit buffering/resampling.
Every output cache is keyed by (clock, tick).
Feedback requires an explicit delay.

If you tell me which clocks you must support on day one (Frame + Render? plus Audio? plus external timecode?), I can propose the minimal bridge set and exact tickId scheme so you don’t paint yourself into a corner.

Unity gives you access to the DSP clock primarily via AudioSettings.dspTime (global audio system time, in seconds). citeturn0search0

1) Read the DSP clock (main thread or any thread)

double t = AudioSettings.dspTime; // seconds

This value advances based on actual samples processed, and is much more precise than Time.time. citeturn0search0

2) Get buffer/block timing (useful to relate to audio callbacks)

AudioSettings.GetDSPBufferSize(out int bufferLength, out int numBuffers);
int sampleRate = AudioSettings.outputSampleRate;
double blockDurationSec = (double)bufferLength / sampleRate;

GetDSPBufferSize tells you how many samples Unity mixes per block (and how many blocks are queued). citeturn0search1

3) In the audio thread: use `OnAudioFilterRead` as your “audio clock tick”

OnAudioFilterRead(float[] data, int channels) is called every time a chunk of audio is processed (often ~20ms-ish depending on platform/settings). citeturn0search19

A common pattern is:

Treat each OnAudioFilterRead call as one audio block tick
Compute dspTime at the start of the block by maintaining your own counter:
- blockStartDsp = initialDsp + blockIndex * blockDuration
- because reading AudioSettings.dspTime from the audio thread can be awkward/unclear in terms of exact alignment to the callback (and you’ll want deterministic block boundaries anyway)

4) Scheduling to the DSP clock (sample-accurate events)

If you’re triggering playback of AudioSource, Unity supports DSP-scheduled playback:

AudioSource.PlayScheduled(double dspTime) (and related scheduling APIs) This is how you line things up precisely to the DSP timeline (beats/timecode style). (This is standard Unity audio workflow; if you want I can pull exact docs for the specific methods you’re using.)

5) Other places DSP clock shows up (handy for AV sync)

Unity’s VideoPlayer can be set to update time based on DSP time for better audio/video sync: VideoTimeUpdateMode.DSPTime. citeturn0search6

Practical guidance for your multi-clock graph

Use AudioSettings.dspTime as the canonical “audio clock” on the main thread. citeturn0search0
Use OnAudioFilterRead as the audio-domain scheduler tick and keep an internal block index to define exact block start times. citeturn0search19turn0search1
Bridge Audio → Frame via a resampler/holder (envelope/FFT results), not by trying to cook render/frame nodes on the audio thread.

If you tell me whether you’re using built-in Unity audio, DSPGraph/DOTS Audio, or FMOD/Wwise, I’ll map the “DSP clock” concept to that stack and recommend the cleanest bridge strategy (especially for live AV latency).