Skip to main content
Glama

Create CHOP recorder

create_chop_recorder

Records CHOP channels over a fixed window, converts to a take, and plays it back. Persists the 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
loopNoWhen true, timer cycles; when false, plays once then holds
nameYesContainer name, e.g. 'chop_rec_hand'
parentNoParent COMP path, defaults to '/'
autoBindNoOptional 'opPath:parName' to auto-bind the Null CHOP output channel
takeNameNoStorage key for persisted taketake1
sourceChopYesPath to source CHOP, e.g. '/project1/null_audio'
lengthSecondsNoTrail window + take duration in seconds (0.25–120)
recordOnCreateNoIf true, sets Record=1 on creation so the trail begins filling immediately
Behavior5/5

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

Beyond the annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false), the description discloses important behaviors: re-entrant updates without rebuilding, persistence of the last take in comp.store, disk storage for large takes, and the timeline-paused playback returning 0. These are valuable details not present in the structured metadata, and there is 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.

Conciseness4/5

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

The description is five sentences and technically dense, but every sentence provides necessary detail: the operational pipeline, re-entrancy, persistence, disk offloading, and timeline behavior. It is appropriately sized for a tool of this complexity, though slightly long for a succinct overview.

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 complexity of the tool (building a multi-node network) and the absence of an output schema, the description is remarkably complete. It covers the internal architecture, the binding endpoint (Null CHOP), persistence, scale limits, and an expected edge-case behavior, which is sufficient for an agent to understand the full scope.

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

Parameters3/5

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

Schema description coverage is 100%, so the parameters are already well-documented. The description adds contextual information about the recording flow (e.g., 'fixed window', 'on Stop') and persistence behavior, which briefly relates to takeName and lengthSeconds, but it does not add significant meaning beyond the schema's own descriptions.

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 builds a CHOP recorder/player container with a specific technical pipeline (Trail CHOP → Table DAT → Datto CHOP → Null CHOP). It distinguishes itself from sibling tools like create_capture_loop by specifying the exact mechanism and the intended use for capturing and playing back CHOP channels.

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

Usage Guidelines4/5

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

The description makes the tool's purpose evident: to record a source CHOP's channels over a fixed window and play it back. It mentions being ready for bind_to_channel, indicating a downstream use case, but it does not explicitly state when not to use this tool or compare it to alternatives like build_chop_chain. Context is clear, but exclusions are absent.

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