overview

TD Overview

Produce a structured report of a TouchDesigner project's component hierarchy, node composition, and health.

Workflow

1. Resolve root to the root-path argument if given, otherwise /project1 if it exists, else / (a project launched by opening the tox as a document has no /project1).

2. Call get_td_info once for context (TouchDesigner version, OS) to include in the report header.

3. Fetch the tree with a single get_td_nodes call on root (includeProperties: false for speed). pattern defaults to "*", and that default makes the tool return the whole subtree recursively — not just direct children — so do not loop per COMP re-fetching paths already returned. Pass pattern: "" explicitly when only the direct children of a path are wanted. Reconstruct the hierarchy from the returned path strings. If the result is too large to report in full, say so explicitly and summarize rather than silently dropping nodes.

4. While traversing, tally node counts per operator family by matching each opType string's suffix (TOP, CHOP, SOP, POP, DAT, MAT, COMP) — this is a naming convention, not a separate field, so classify accordingly.

5. Identify notable chains on a best-effort basis using naming and opType, since get_td_nodes doesn't report wiring/connections directly: clusters of TOPs suggesting a render network (e.g. render, camera, light, geo family nodes co-located under one COMP), or CHOP/DAT nodes suggesting an audio chain (audiofilein, audiodevicein/out, audiomovie*). Also flag COMPs whose children are almost entirely one family (a pure-TOP compositing COMP, a pure-CHOP control-rig COMP) as likely functional units worth naming in the report even without an obvious chain label. State plainly that these groupings are inferred from names and types, not verified wiring — a caveat the report should carry, not hide.

6. Call get_td_node_errors with nodePath set to root to collect every error in the whole scope in one call (it covers descendants automatically).