Skip to main content
Glama

Create CHOP recorder

create_chop_recorder

Captures source CHOP channels over a fixed window, snapshots to a Table DAT, and plays back the take via Datto CHOP. Persists last take across .toe reloads.

Instructions

Build a CHOP recorder/player container that captures a source CHOP's channels over a fixed window using a Trail CHOP, snapshots the trail into a Table DAT on Stop, and plays the take back via a Datto CHOP indexed by a Timer CHOP–driven Lookup CHOP, terminating on a Null CHOP ready for bind_to_channel. Re-entrant: re-running with the same name updates controls without rebuilding. The last take is persisted in comp.store so it survives a .toe reload. Large takes (nchan × samples > 250k) are saved to disk instead of stored in the .toe. Note: time-dependent playback reads 0 when the TD timeline is paused — that is expected behavior.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesContainer name, e.g. 'chop_rec_hand'
parentNoParent COMP path, defaults to '/'
sourceChopYesPath to source CHOP, e.g. '/project1/null_audio'
lengthSecondsNoTrail window + take duration in seconds (0.25–120)
takeNameNoStorage key for persisted taketake1
loopNoWhen true, timer cycles; when false, plays once then holds
recordOnCreateNoIf true, sets Record=1 on creation so the trail begins filling immediately
autoBindNoOptional 'opPath:parName' to auto-bind the Null CHOP output channel
Behavior5/5

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

The description discloses key behaviors beyond the annotations: re-entrancy, persistence of the last take in comp.store, large-take disk offloading, and a known limitation (time-dependent playback reads 0 when paused). The annotations only declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true, so the description adds substantial behavioral context without contradiction.

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 description is a single coherent paragraph that front-loads the main purpose and then adds essential details. Every sentence serves a purpose (behavior, re-entrancy, persistence, large-take handling, limitation note). It is not overly verbose, though it could be slightly more structured (e.g., bullet points for clarity). The efficiency is high given the complexity.

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

Completeness4/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, 2 required, no output schema), the description covers the core workflow, re-entrancy, persistence, large-take behavior, and a known limitation. It sets clear expectations for the agent (e.g., the Null CHOP output ready for bind_to_channel). While it does not detail every edge case (e.g., what happens if sourceChop changes after creation), the provided information is sufficient for effective usage.

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?

With 100% schema description coverage, the baseline is 3. The description adds value by explaining the overall workflow (e.g., how 'takeName' acts as a storage key, 'recordOnCreate' sets Record=1, 'autoBind' relates to the Null CHOP). While individual parameter details are already in the schema, the description contextualizes their role in the system, justifying a slightly higher score.

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 identifies the tool's purpose: building a CHOP recorder/player container that captures and replays channels via specific TouchDesigner components (Trail CHOP, Table DAT, Datto CHOP, etc.). The verb 'Build' and resource 'CHOP recorder/player container' make the action and output distinct. The description differentiates from siblings like 'create_capture_loop' by detailing the internal mechanism, ensuring unique identity.

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 re-entrant behavior ('re-running with the same name updates controls without rebuilding') and persistence details, but it does not explicitly state when to use this tool versus alternatives (e.g., other capture tools among siblings). It provides context for the typical use case (recording and playing back CHOP channels) without offering exclusion criteria or comparisons.

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