Skip to main content
Glama

Create generative audio

create_generative_audio

Synthesize audio by building an oscillator, FM, or noise chain in TouchDesigner. Control frequency, waveform, volume, and opt-in hardware playback.

Instructions

SYNTHESIZE audio — generate sound rather than react to it. Builds an audio synthesis chain ending on a Null CHOP carrying the signal: 'oscillator' (a single tone, choose sine/triangle/sawtooth/square + frequency), 'fm' (two oscillators, one frequency-modulating the other for metallic/bell timbres), or 'noise' (a Noise CHOP shaped by a low-pass filter for textures). A Volume gain sets the level. Playback is opt-in: set to_device=true to route it to an Audio Device Out CHOP (default off, so the build stays silent and never prompts for audio hardware). Creates a new baseCOMP under parent_path holding the synth chain. The output Null feeds create_spectrum/create_waveform, bind_to_channel, or the speakers. Audio CHOPs are time-dependent — the signal is silent while the TD timeline is paused. Returns a summary plus a JSON block with the container path, created node paths, the audio Null path, the synth settings, the device-out path (if any), any node errors, and warnings (no preview image — the output is a CHOP, not a TOP).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
synthNoSynthesis method. 'oscillator' = a single tone-generating Audio Oscillator CHOP. 'fm' = two oscillators where one modulates the other's frequency (classic FM, metallic/bell timbres). 'noise' = a Noise CHOP shaped by a low-pass Audio Filter (wind/hiss/percussive textures).oscillator
frequencyNoCarrier / oscillator base frequency in Hz (e.g. 220 = A3).
waveformNoOscillator wave shape (ignored for the 'noise' synth).sine
fm_ratioNo(fm) Modulator frequency as a multiple of the carrier (modulator = frequency × ratio).
fm_depthNo(fm) Modulation depth — the peak frequency deviation in Hz applied to the carrier.
volumeNoOutput level, 0..1 (a gain on the final signal). Start moderate to protect ears/speakers.
to_deviceNoPlay the synthesized audio out through an Audio Device Out CHOP. Default OFF (opt-in) so the build never opens audio hardware — keeping it silent-safe and avoiding the macOS audio-permission prompt. Turn on only when you actually want sound out the speakers.
expose_controlsNoWhen true (default), expose live Frequency / Volume knobs (and FmRatio / FmDepth for the fm synth).
parent_pathNoParent network where the synth container is created (default '/project1')./project1
Behavior4/5

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

Annotations indicate non-readonly, non-destructive, open world. The description adds that it creates a new baseCOMP, that Audio CHOPs are time-dependent (silent while timeline paused), and mentions opt-in device routing to avoid hardware prompts. No contradictions 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 a single paragraph that is detailed yet reasonably concise, front-loading the core purpose. Some repetition with schema, but overall well-structured.

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 (9 parameters, multiple synth types, output handling), the description covers creation, synth types, volume control, to_device behavior, time-dependency, and return format including warnings. No output schema, so the description does a good job providing necessary context.

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?

Input schema has 100% coverage with detailed parameter descriptions. The description integrates parameter info into the narrative (e.g., synth methods, volume gain) but does not add significant new meaning beyond the schema.

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 starts with 'SYNTHESIZE audio — generate sound rather than react to it,' clearly stating the tool's purpose: generative audio synthesis. It distinguishes from sibling tools like create_audio_reactive or bind_audio_reactive that react to existing audio.

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 explains that playback is opt-in via to_device=true, mentions how the output feeds other tools like create_spectrum/create_waveform, and warns about the macOS permission prompt. However, it does not explicitly list alternative tools for when not to use this one.

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