Skip to main content
Glama

td_timeline_run

Walk a TouchDesigner timeline frame-by-frame as a job for history-dependent effects (Feedback TOPs, live audio); save chosen frames or just advance to warm up state.

Instructions

Walk the timeline frame by frame and save a TOP's frames — as a job.

Reach for this instead of a td_exec loop whenever frames depend on what came before them: live audio analysis, Feedback TOPs, trails, anything with history. It returns at once with a job id; poll td_timeline_status, stop with td_timeline_cancel. No request holds TouchDesigner for more than one step, so the 30 s limit on a call does not apply to the walk.

frames is the walk, e.g. "1..994". save picks the frames to write, e.g. "92..217,459..541" (default: every frame walked), into output, a template such as "/renders/f{frame:04d}.png". Without output nothing is saved and the job only advances the timeline — the way to warm history up to frame N before td_render, and then the timeline is held paused at N.

What it handles so you do not have to: it pauses the timeline and gives the play mode back at the end (so live audio is repeatable); it walks every frame consecutively, from the start of frames when from_start, otherwise from the first frame to save; it waits settle application frames between steps (2 was measured repeatable for live audio — do not go lower with audio); and its steps cannot run twice.

tiles=2 renders past the licence's 1280 cap as 2x2 quarters, by cropping the Render TOP(s) named in render (or path, if it is one). Put {tile} in output: 0 top left, 1 top right, 2 bottom left, 3 bottom right. Each quarter is a whole walk of its own, four times the time, because a Feedback TOP only builds a quarter's history right under that quarter's crop. Nothing resets a Feedback TOP between passes, so each quarter's first frames carry the last one's tail — a decaying trail forgets it, an accumulator does not. The crop goes back to 0..1 however the job ends.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
holdNo
pathYes
saveNo
tilesNo
framesYes
outputNo
renderNo
settleNo
from_startNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.2.0

TDQS

A4.9/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does so thoroughly. It discloses that the call returns immediately with a job id, pauses the timeline, restores play mode at the end, walks frames consecutively, waits settle frames, prevents duplicate steps, resets crops, and preserves Feedback TOP state across tile passes.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but dense and well-structured, with short paragraphs, inline code examples, and scoping conditions front-loaded. Given the tool's complexity and complete lack of annotations or schema descriptions, the length is justified and every paragraph adds actionable information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The definition covers the full job lifecycle, return behavior, timeline state management, frame-selection semantics, output templating, tile rendering caveats, and the no-output warm-up use case. It also names the sibling status/cancel tools. For a complex asynchronous tool with no annotations, this is unusually complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Since schema description coverage is 0%, the description must explain the parameters, and it does: frames, save, output, tiles, render/path, settle, and from_start are all given concrete syntax or behavior. However, the hold parameter is never explicitly explained, leaving one of the nine parameters ambiguous.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Walk the timeline frame by frame and save a TOP's frames — as a job.' It also differentiates itself from siblings by explicitly naming td_exec and td_render and explaining the job-based async behavior, so an agent can tell exactly what this tool is for.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit when-to-use guidance: 'Reach for this instead of a td_exec loop whenever frames depend on what came before them.' It also names the alternatives for polling and cancellation (td_timeline_status, td_timeline_cancel) and explains when to use it as a warm-up step before td_render.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.