Music Studio

Play Live Pattern

play-live-pattern

Read-only

Live-code music in Strudel (TidalCycles mini-notation in JavaScript) and play it in a player the user can edit. Layer drums, bass and melody with stack(): 71 drum-machine banks, 128 GM instruments, synths and a full effects chain. Add .pianoroll() for a live piano roll (or .punchcard()/.scope()/.spectrum(), one per pattern), pass visuals for a ready-made animation and theme for the editor colours. Each call creates a NEW player. Optional, when you want more (get-strudel-guide topic in brackets): shader backgrounds that follow the music — start with await initHydra(), lock to the beat with H(pattern), react to the sound with () => a.fft[0] ('hydra'); canvases, scenes and spoken lines for music videos and films ('stage', 'film'); taps, faders, pads and controls you draw, played by the user; tilt and mic, which follow the phone on the browser player (a chat's frame usually blocks them) ('interactive'); complete pieces ('gallery'). To jam back and forth, or to change a piece while it plays, pass session: true, then use update-session and get-session.

The Strudel REPL renders inline with an editable code editor, visualizations, and playback controls.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "code": "<code>"
    },
    "name": "play-live-pattern"
  }
}

Input Schema

Name	Required	Description
`bpm`	No	Tempo in BPM (40-300). Converts to setcps() automatically.
`code`	Yes	Strudel pattern code. Uses TidalCycles mini-notation in JavaScript. Use stack() to layer drums, bass, and melody. Set tempo with setcps(bpm/60/4) or use the bpm parameter. The REPL plays the LAST expression: setup lines (await initHydra(), all(), setcps()) go BEFORE the pattern. Double quotes are mini-notation — use single quotes for plain strings and URLs. One draw method per pattern; pass a.fft values as functions (() => a.fft[0]).
`theme`	No	Editor colour scheme. It also sets the ground the visuals sit on, so pick a dark one when the visual is the point (e.g. 'nord', 'sonicPink', 'tokyoNight').
`title`	No	Pattern title displayed in the widget header (e.g. 'Midnight Rain').
`session`	No	Optional: keep this player open as a live session. update-session then swaps new code in on the bar, and get-session reports what played and what the user did. For a jam, or a piece you change while it plays. Give the user something to play — taps, a fader, a grid (topic 'interactive') — or they answer by editing the code and pressing Pass. The log is kept until 2 hours idle.
`visuals`	No	A ready-made visual for code that has none of its own: pianoroll, punchcard, scope or spectrum (drawn behind the code), or hydra-kaleid, hydra-pulse, hydra-wash or hydra-feed (shader backgrounds). It only fills a layer the code leaves empty, and shaders are skipped for viewers who prefer reduced motion. Your own visual is the better result (topics 'visuals' and 'hydra').
`autoplay`	No	Start playing immediately (default: true). May require user click due to browser autoplay policy.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 7, 2026

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

Changed3 schema fields changedOct 4, 2026

changedInput schema / properties / session / description

Previous value: -"Open a LIVE SESSION: this player stays open as one performance. update-session swaps in new code on the next bar without a new player and says whether it ran; get-session reads the player's runtime reports and what the user did (taps, code edits, handing you the turn). Use it to iterate on a long piece, to check that a piece really played, or to jam back-to-back. Its log (reports, taps, edits, your updates) is kept on the server until 2 hours idle."New value: +"Optional: keep this player open as a live session. update-session then swaps new code in on the bar, and get-session reports what played and what the user did. For a jam, or a piece you change while it plays. Give the user something to play — taps, a fader, a grid (topic 'interactive') — or they answer by editing the code and pressing Pass. The log is kept until 2 hours idle."

changedInput schema / properties / theme / description

Previous value: -"Editor colour theme; the visuals stage and its readability scrim are derived from it, so it also decides whether a shader sits on a dark or light ground — prefer a dark one when the visual is the point (e.g. 'nord', 'sonicPink', 'tokyoNight'). Not carried into share links or the browser fallback."New value: +"Editor colour scheme. It also sets the ground the visuals sit on, so pick a dark one when the visual is the point (e.g. 'nord', 'sonicPink', 'tokyoNight')."

changedInput schema / properties / visuals / description

Previous value: -"Ready-made visual, for when the code has none of its own. pianoroll/punchcard/scope/spectrum draw onto the 2D canvas behind the code; hydra-kaleid (rotating kaleidoscope), hydra-pulse (shape driven by a rhythm), hydra-wash (slow ambient noise) and hydra-feed (the piano roll mirrored and trailed) are WebGL shader backgrounds. A preset fills the MISSING layer: a hydra preset is skipped only if the code already calls initHydra(), a 2D preset only if the code already has a draw method — so hydra-wash layers happily under your own .pianoroll(). Hydra presets are dropped for viewers who prefer reduced motion. Writing your own visual is still the better result (draw methods: topic 'visuals'; shaders: topic 'hydra')."New value: +"A ready-made visual for code that has none of its own: pianoroll, punchcard, scope or spectrum (drawn behind the code), or hydra-kaleid, hydra-pulse, hydra-wash or hydra-feed (shader backgrounds). It only fills a layer the code leaves empty, and shaders are skipped for viewers who prefer reduced motion. Your own visual is the better result (topics 'visuals' and 'hydra')."

Changed1 schema field changedOct 2, 2026

addedInput schema / properties / session

Added value: +{
+  "description": "Open a LIVE SESSION: this player stays open as one performance. update-session swaps in new code on the next bar without a new player and says whether it ran; get-session reads the player's runtime reports and what the user did (taps, code edits, handing you the turn). Use it to iterate on a long piece, to check that a piece really played, or to jam back-to-back. Its log (reports, taps, edits, your updates) is kept on the server until 2 hours idle.",
+  "type": "boolean"
+}

Changed3 schema fields changedSep 8, 2026

changedInput schema / properties / code / description

Previous value: -"Strudel pattern code. Uses TidalCycles mini-notation in JavaScript. Use stack() to layer drums, bass, and melody. Set tempo with setcps(bpm/60/4) or use the bpm parameter."New value: +"Strudel pattern code. Uses TidalCycles mini-notation in JavaScript. Use stack() to layer drums, bass, and melody. Set tempo with setcps(bpm/60/4) or use the bpm parameter. The REPL plays the LAST expression: setup lines (await initHydra(), all(), setcps()) go BEFORE the pattern. Double quotes are mini-notation — use single quotes for plain strings and URLs. One draw method per pattern; pass a.fft values as functions (() => a.fft[0])."

changedInput schema / properties / theme / description

Previous value: -"Editor colour theme — pick to match the mood (e.g. 'nord', 'sonicPink', 'githubLight')."New value: +"Editor colour theme; the visuals stage and its readability scrim are derived from it, so it also decides whether a shader sits on a dark or light ground — prefer a dark one when the visual is the point (e.g. 'nord', 'sonicPink', 'tokyoNight'). Not carried into share links or the browser fallback."

changedInput schema / properties / visuals / description

Previous value: -"Ready-made visual, for when the code has none of its own. pianoroll/punchcard/scope/spectrum draw onto the 2D canvas behind the code; hydra-kaleid (rotating kaleidoscope), hydra-pulse (shape driven by a rhythm), hydra-wash (slow ambient noise) and hydra-feed (the piano roll mirrored and trailed) are WebGL shader backgrounds. Ignored if the code already visualises itself — writing your own .pianoroll() or initHydra() shader is still the better result (see get-strudel-guide topic 'visuals')."New value: +"Ready-made visual, for when the code has none of its own. pianoroll/punchcard/scope/spectrum draw onto the 2D canvas behind the code; hydra-kaleid (rotating kaleidoscope), hydra-pulse (shape driven by a rhythm), hydra-wash (slow ambient noise) and hydra-feed (the piano roll mirrored and trailed) are WebGL shader backgrounds. A preset fills the MISSING layer: a hydra preset is skipped only if the code already calls initHydra(), a 2D preset only if the code already has a draw method — so hydra-wash layers happily under your own .pianoroll(). Hydra presets are dropped for viewers who prefer reduced motion. Writing your own visual is still the better result (draw methods: topic 'visuals'; shaders: topic 'hydra')."

Changed3 schema fields changedSep 8, 2026

addedInput schema / properties / code / maxLength
```
Added value: +65536
```

addedInput schema / properties / theme

Added value: +{
+  "description": "Editor colour theme — pick to match the mood (e.g. 'nord', 'sonicPink', 'githubLight').",
+  "enum": [
+    "strudelTheme",
+    "algoboy",
+    "archBtw",
+    "androidstudio",
+    "atomone",
+    "aura",
+    "bbedit",
+    "blackscreen",
+    "bluescreen",
+    "bluescreenlight",
+    "CutiePi",
+    "darcula",
+    "dracula",
+    "duotoneDark",
+    "eclipse",
+    "fruitDaw",
+    "githubDark",
+    "githubLight",
+    "greenText",
+    "gruvboxDark",
+    "gruvboxLight",
+    "sonicPink",
+    "materialDark",
+    "materialLight",
+    "monokai",
+    "noctisLilac",
+    "nord",
+    "redText",
+    "solarizedDark",
+    "solarizedLight",
+    "sublime",
+    "teletext",
+    "tokyoNight",
+    "tokyoNightDay",
+    "tokyoNightStorm",
+    "vscodeDark",
+    "vscodeLight",
+    "whitescreen",
+    "xcodeLight"
+  ],
+  "type": "string"
+}

addedInput schema / properties / visuals

Added value: +{
+  "description": "Ready-made visual, for when the code has none of its own. pianoroll/punchcard/scope/spectrum draw onto the 2D canvas behind the code; hydra-kaleid (rotating kaleidoscope), hydra-pulse (shape driven by a rhythm), hydra-wash (slow ambient noise) and hydra-feed (the piano roll mirrored and trailed) are WebGL shader backgrounds. Ignored if the code already visualises itself — writing your own .pianoroll() or initHydra() shader is still the better result (see get-strudel-guide topic 'visuals').",
+  "enum": [
+    "none",
+    "pianoroll",
+    "punchcard",
+    "scope",
+    "spectrum",
+    "hydra-kaleid",
+    "hydra-pulse",
+    "hydra-wash",
+    "hydra-feed"
+  ],
+  "type": "string"
+}

First observedJun 20, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnly, non-destructive, non-idempotent and closed-world, so the safety profile is covered. The description adds genuinely useful behavioural facts beyond them: each call creates a NEW player, autoplay may be blocked by browser policy, visuals are skipped for reduced-motion viewers, the session log is kept until 2 hours idle, and phone tilt/mic are usually blocked in a chat frame. Residual tension: 'creates a NEW player' implies a state-creating side effect that sits awkwardly with readOnlyHint=true, but it is disclosed rather than hidden and no output/return shape is described.

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

Conciseness3/5

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

The core purpose is correctly front-loaded in sentence one, and the decisive sibling routing (session -> update-session/get-session) sits at the end where it is easy to find. However, the middle 'Optional, when you want more' sentence is a ~120-word packed enumeration of hydra/stage/film/interactive/gallery topics that is hard to parse and largely irrelevant to invoking the tool correctly, pushing length past what the task needs.

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 code-execution tool with 7 parameters, one required, no output schema and a rich enum surface, the definition covers what an agent needs: code authoring rules (last expression plays, setup lines first, quoting conventions, one draw method per pattern), tempo handling, session lifecycle, and what the user will actually see. Nothing needed to call it correctly is missing.

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 every parameter (bpm range, code, theme, title, session, visuals, autoplay) is already documented in the schema, which sets the baseline at 3. The description adds modest extra meaning: session is tied to update-session/get-session and to the 2-hour log window, and visuals is constrained to empty layers. Most of the parameter text otherwise restates the schema (e.g. the setcps and reduced-motion notes already live on bpm and visuals).

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 first sentence states a specific verb and resource ('Live-code music in Strudel ... and play it in a player the user can edit') and immediately names the rendering target (the Strudel REPL with inline editor and playback controls). It distinguishes itself from its siblings by naming update-session, get-session and get-strudel-guide by name and role. An agent can tell this apart from play-sheet-music or convert-abc-to-strudel without opening any schema.

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?

Usage is routed explicitly: use `visuals` only as a fallback for code with no visual of its own ('It only fills a layer the code leaves empty ... Your own visual is the better result'), use `session: true` specifically 'to jam back and forth, or to change a piece while it plays', and then use update-session/get-session. Optional advanced capabilities are listed with the get-strudel-guide topic to consult, which is an explicit next-step routing rather than vague guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Music Studio tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.