Skip to main content
Glama

Create time echo

create_time_echo

Creates echo trails, slit-scan, or time-displace effects on a video input in TouchDesigner.

Instructions

EXPERIMENTAL — Apply a per-pixel time effect to a source TOP: echo trails, slit-scan, or per-pixel time displacement (the 'time machine' melt/slice look). Builds a container COMP that selects the source by absolute path (no cross-container wire) and then, by mode: echo — a feedbackTOP (wired input + forced resolution so the loop is not black) blended over the live frame at opacity=feedback to leave fading ghost trails; slit_scan — a cacheTOP buffering frames and a time-machine TOP reading different rows from different points in time; time_displace — the same cache read back through a luminance gradient (displace_top or a built-in vertical ramp) so bright pixels show older frames. The time-machine read operator is PROBED LIVE (timeMachineTOP → cacheSelectTOP fallback) because the optype name varies by TD build; the feedback opacity par (opacity → fadeval) and cache-depth par (cachesize → maxframes) are also set defensively. Every par/connect failure is collected as a warning and the chain still returns its output Null — UNVERIFIED across TD builds; tune live. Ends with a Null TOP 'out'.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
parent_pathNoWhere to build the time-echo chain (a COMP path, e.g. '/project1')./project1
nameNoBase name for the container COMP that holds the chain.time_echo
source_topYesPath of the input TOP to apply the time effect to (e.g. '/project1/moviefilein1' or a Null TOP). REQUIRED.
modeNoecho: recursive feedback trails — each frame leaves a fading ghost (the classic 'echo trails' / time-blur look, driven by `feedback`). slit_scan: buffer N frames in a cache and read different rows from different points in time (rolling 'time slice' wipe). time_displace: per-pixel time offset driven by a gradient (`displace_top`) — bright pixels show older frames, dark show newer (the 'time_machine' melt/warp). slit_scan and time_displace both buffer frames in a cacheTOP and read them back with a time-machine TOP.echo
framesNoBuffer depth / cache size in frames for slit_scan and time_displace (how far back in time pixels can be pulled). Ignored in echo mode (feedback is recursive, not frame-indexed). Larger = longer time range but more GPU memory.
feedbackNoEcho trail strength [0–1] for echo mode — opacity of the fed-back previous frame blended over the current one. Higher = longer, more persistent trails (0.5 = balanced; 0.9+ = very smeary). Ignored in slit_scan / time_displace.
displace_topNotime_displace mode only: path of a TOP whose luminance maps each pixel to a time offset (a gradient/ramp/noise — bright = further back in time). Omit to use a built-in vertical ramp (rampTOP) so the effect works out of the box. Ignored in echo / slit_scan.
resolutionNoForced output resolution [width, height] in pixels. A fixed resolution is REQUIRED for the feedback path (echo mode) so the loop has a stable frame from cook 0 and does not stay black.
Behavior4/5

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

Beyond the annotations (which indicate non-destructive mutation and open-world), the description reveals that the tool builds a container COMP, selects source by absolute path, handles fallbacks for operator name variations, collects warnings on failures, and may return a Null output. It also labels the tool as 'EXPERIMENTAL' and warns about TD build variations. No contradiction with annotations.

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

Conciseness3/5

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

The description is verbose and contains implementation details that may not be essential for an agent deciding to use the tool (e.g., internal TD operator fallbacks). While the main purpose is front-loaded, the length reduces clarity and some redundancy exists (e.g., repeated mode explanations).

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?

Given the tool's complexity (8 parameters, 3 modes, no output schema), the description is remarkably complete. It explains each mode's mechanism, parameter interactions, edge cases (e.g., feedback loop stability, fallback operators), and the experimental nature. The agent gains a solid understanding of what happens during execution.

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?

The input schema already covers all 8 parameters with descriptions (100% coverage). The description adds meaningful context for several parameters: specifying that resolution is REQUIRED for echo mode to avoid black feedback, explaining the role of feedback opacity and cache-depth, and clarifying that displace_top can be omitted for a built-in ramp. This extra behavioral info aids the agent in configuring the tool.

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

Purpose4/5

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

The description explicitly states the tool applies a per-pixel time effect to a source TOP and details three modes (echo, slit_scan, time_displace). It is specific about the resource and action, but does not directly contrast with sibling tools like create_feedback_network or create_datamosh, leaving some differentiation implicit.

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

Usage Guidelines3/5

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

The description explains when each mode might be used (e.g., 'echo trails', 'slit-scan', 'time machine melt/slice look') and notes the experimental status. However, it lacks explicit guidance on when to choose this tool over alternatives (e.g., creating a feedback network or datamosh), and does not state prerequisites or conditions for use.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Pantani/tdmcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server