Skip to main content
Glama

Create time echo

create_time_echo

Apply echo trails, slit-scan, or per-pixel time displacement to a TouchDesigner TOP by building a container COMP with feedback and cache TOPs.

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
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
nameNoBase name for the container COMP that holds the chain.time_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.
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.
source_topYesPath of the input TOP to apply the time effect to (e.g. '/project1/moviefilein1' or a Null TOP). REQUIRED.
parent_pathNoWhere to build the time-echo chain (a COMP path, e.g. '/project1')./project1
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.
Behavior5/5

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

The description richly discloses behavioral traits beyond annotations: it builds a container COMP, selects source by absolute path with no cross-container wire, probes live for time-machine operator, sets pars defensively, collects failures as warnings, and returns a Null TOP 'out'. This far exceeds the sparse annotation set and prepares the agent for fallbacks and unverified behavior.

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

Conciseness4/5

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

The text is long but structured by mode, front-loading the core purpose and then detailing mode-specific behaviors and failure handling. Every sentence contributes necessary technical context, making it dense but appropriately sized for the tool's complexity.

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?

For a complex tool with no output schema, the description covers the container build, all three modes, parameter roles, fallbacks, warning behavior, and the final Null TOP output. No critical gaps prevent an agent from understanding what the tool does and how to invoke it.

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?

Schema coverage is 100%, so the baseline is 3. The description adds value by explaining how parameters interact, such as feedback opacity mapping, forced resolution for echo mode, and cache depth for slit_scan/time_displace, enriching the schema's already-detailed descriptions without redundancy.

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 clearly states the tool applies a per-pixel time effect to a source TOP, enumerating three specific modes: echo trails, slit-scan, and per-pixel time displacement. It distinguishes itself from sibling creation tools by specifying the exact effect family and its container-building behavior.

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 opens with 'EXPERIMENTAL' and warns 'UNVERIFIED across TD builds; tune live,' implying cautious use but not offering explicit alternatives. It does not mention sibling tools like create_slit_scan for when this tool should be preferred, so usage guidance is implied rather than explicit.

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/lucasmaher-hash/touch-designer-mcp'

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