Skip to main content
Glama

Create Euclidean sequencer

create_euclidean_sequencer

Builds a Euclidean rhythm sequencer in TouchDesigner using Bjorklund's algorithm to distribute pulses across steps, writes the pattern to a Table DAT, and fires beat-synced dispatches.

Instructions

Build a Euclidean rhythm sequencer: given pulses evenly distributed across steps via Bjorklund's algorithm (with optional cyclic rotation), it writes the resulting on/off pattern to a Table DAT and fires one dispatch per active step on each beat boundary. The deterministic, mathematically-grounded sibling of create_beat_grid_sequencer — program rhythms by musical intent (e.g. E(3,8) tresillo, E(5,8) cinquillo, E(4,16) four-on-the-floor) rather than by hand-editing cells. Sweep the Pulses/Rotation custom parameters live and the table re-shapes in place. action=param sets a custom parameter to on_value/off_value per step; action=cue recalls a cue per active step (cues stored with manage_cue). NOTE: beat-callback timing is UNVERIFIED offline — check op().time.play if steps don't fire when the TD timeline is paused.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoName for the sequencer COMP.euclidean
paramNo(action=param) The custom-parameter name on the target COMP to set on each active step.
stepsNoNumber of steps in the Euclidean grid.
actionNoparam: set a target custom-parameter value per active step; cue: recall a named cue per active step (cues stored with manage_cue).param
pulsesNoNumber of active pulses distributed evenly across `steps` via Bjorklund's algorithm. Clamped to <= steps at build time.
targetYesCOMP whose parameter or cue each active step fires on a beat boundary.
on_valueNo(action=param) Value written into the table cell for active steps.
rotationNoCyclic rotation of the generated pattern (downbeat offset).
off_valueNo(action=param) Value written into the table cell for inactive steps.
bpm_sourceNoPath to an existing Beat CHOP or tempo source. Omit to create a new Beat CHOP (on the global TD tempo).
parent_pathNoParent COMP path to create the sequencer inside./project1
Behavior5/5

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

The description discloses far more than the annotations (readOnlyHint false, openWorldHint true, destructiveHint false). It details side effects: writes to a Table DAT, fires dispatches per active step, creates/uses a Beat CHOP, re-shapes table live when parameters sweep, and even includes a caveat about unverified timing when the TD timeline is paused. This goes well beyond what annotations convey.

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 dense but well-structured: opening with the core function, then distinguishing from its sibling, then explaining action modes, and ending with a critical caveat. Every sentence adds value, and the front-loading makes it easy to parse quickly.

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 an 11-parameter tool with no output schema, the description covers the full scope: what it builds, how it works algorithmically, what outputs are written, how parameters relate to behavior, and a limitation. It fully equips an agent to understand the tool's operation and side effects without needing an output schema.

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 baseline is 3. The description adds meaningful context beyond schema descriptions: it explains the mathematical relationship between pulses and steps, gives canonical musical patterns, and notes the live-sweep behavior for Pulses/Rotation. It doesn't detail every parameter, but the schema already does that.

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: 'Build a Euclidean rhythm sequencer' and details the algorithm (Bjorklund's) and output (Table DAT, dispatches). It explicitly distinguishes itself from create_beat_grid_sequencer as the deterministic, mathematically-grounded sibling, making its unique role clear.

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 explicitly states when to use this tool: to program rhythms by musical intent (with examples like E(3,8), E(5,8), E(4,16)) rather than hand-editing cells, and names the alternative create_beat_grid_sequencer. It also clarifies the two action modes (param vs cue) and cautions about unverified beat-callback timing, giving practical usage guidance.

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