Reads the Strudel code currently playing in the Moontide page, i.e. the last code the page confirmed, including edits the user evaluated by hand; returns 'Nothing is playing yet.' before anything played, with a template of a song structure to start from. Before Moontide is started it says so and starts nothing; after the start its reply also names the page address, the port and the tab title. Call it before every change.

Returns the Strudel reference for @strudel/repl 1.3.0, the version the Moontide page loads: facts about what exists and how to write it, not what to choose. Topics: tidal-differences, mini-notation, functions, effects, sounds, theory, transitions, structure, midi, settings, motif. Call it without a topic for the index. Strudel is JavaScript, not TidalCycles: read tidal-differences before writing Strudel from Tidal habits.

Replaces the music in the Moontide page with new Strudel code; the new pattern takes over within a fraction of a second, mid-cycle, without stopping the music. To change part of an existing piece, edit_code sends only the change; set_code is for a new piece or a rewrite of most of its lines. With at: 'bar' or at: 'phrase' the code is checked at once and takes over on the next bar line or the next phrase line instead (a bar is one cycle of 4 beats; a phrase is 4 cycles, or phraseCycles, counted from Play); the reply gives the cycle and about how many seconds, a newer change replaces a waiting one, and Stop cancels it. When the tempo changes, the reply gives it in BPM. Every call runs the whole program again, so a getTime() anchor restarts at each change; a transition that must keep running takes .timeline(id), which keeps its anchor as long as the code keeps the same id (see the transitions topic). Double-quoted and backtick strings are parsed as mini-notation wherever they appear, helpers included, while single-quoted strings stay plain JavaScript (see the tidal-differences topic). When Moontide is not started yet, set_code starts it first: its page opens in a new browser tab and the call waits up to 30 seconds for that page to connect. Before changing existing music, call get_code and build on what it returns, including hand edits. Keep what the user said matters; if a small request needs a full rewrite and the user said what matters, ask first, otherwise rewrite and say so. When a request is vague, act on your own reading of it instead of asking first. Returns the code as confirmed by the page. Pass a short label saying what changed; every version that plays is kept in the history. Then tell the user in one line what you chose: the musical terms, plus a short image in plain words.

Changes part of the code that will play by exact text replacement, sending only the change. Use it to change an existing piece; use set_code for a new piece or a rewrite of most of its lines. Each edit has old_string, new_string and optional replace_all, as in your own Edit tool. Every old_string must match exactly once (or set replace_all), and every edit is matched against the code as it is before this call, so edits must not overlap and one edit cannot match text another edit writes. An edit that matches nowhere, matches more than once, overlaps another edit or changes nothing refuses the whole call with the reason and the edit number: nothing is applied and nothing reaches the page. CRLF counts as LF. The edits apply to the newest code that will play: the change waiting for its bar or phrase line when one waits (get_code shows the code playing until then), otherwise the code playing now with the user's evaluated hand edits; text typed in the page but not evaluated is replaced, as with set_code. Pass base, the version number get_code shows, to have the edit refused when the music moved on since. at, phraseCycles and label work as in set_code, and the edited program goes through the same checks, history entry and notices. The reply gives the version, when the change takes over and the changed lines with a few lines around them, not the whole program; get_code returns it. Put all replacements for one change in a single call: a second edit_code sent before the first reply is refused. It edits music that already plays, so before Moontide is started it is refused and starts nothing: use set_code first. Call get_code before changing existing music.

Lists the versions of the music that played, newest first, one per row: "#id — time (UTC) — origin — "label" — first line of code". Ids never change. Rows without "#" mark where a Claude session started. The newest version row is usually what plays now; "the previous version" is the next version row down, "3 changes ago" is three version rows below the newest. Pass limit to see more than 20. Pass filter to find a version by a word from its label, code or favorite name; pass favorites: true to list favorites.

Keeps a version as a named favorite, by its id from list_history (the version playing now is the one shown as v{id} in the page top bar). Favorites are never dropped from the history. Favoriting the same id again renames it. List favorites with list_history and favorites: true.

Plays a past version again, by its id from list_history, in one call: it takes over within a fraction of a second without stopping the music, with the same checks as set_code. The restore is added to the history as a new version ("restored from #id"); nothing is rewritten. Returns the code as confirmed by the page. A restore always takes over at once and replaces a change that waits for a bar or phrase line. The old version replaces the music at once; when the user asked for gradual changes this session, bring it in with set_code and a transition instead. Like set_code, it starts Moontide first when it is not started yet, but only for an id that exists in the history.

Closes a request typed in the Moontide page without changing the music. Use outcome answered when the request was answered in words, declined when it will not or cannot be done. Give one sentence of at most 200 characters; the page shows it under the request. A change that answers a request names it with answering on set_code, edit_code or restore_version instead. An id that is not an open request is refused and nothing changes.

Stops all sound in the Moontide page right away, even when the current code is broken. The code stays in the editor; get_code still returns it, and the next set_code starts playing again. Before Moontide is started it says so and starts nothing.

When the user has described their instruments, call this before writing MIDI code. Lists the MIDI instruments the user described in instruments.json, as facts: for each one its id, model, exact port name, whether it is connected right now, its channels and their roles, how many sounds it has, its bank select, its reset, whether it follows MIDI clock and its controls. Pass instrument (an id from that list) to get that instrument's full sound list, with the program number sent for each sound and its bank when it has one. A sound is chosen in the code with the sound option of .midi(). An instrument with a sound catalog shows how many sounds the catalog holds and its categories; search_midi_sounds finds them. For an instrument whose model describes settings it lists the tone, part and scene setting names with their ranges, the tone ones per engine, and the settings topic of get_strudel_reference has their rules; with instrument set it gives the engine of each sound the catalog places in one. For an instrument with a rhythm channel it says how a kit goes out and which drum map applies; with instrument set it lists each drum map as note numbers and drum names, a kit's own map only when it differs from the model's, and says when a kit has no known map. Drum notes are written as note numbers in the code. It also says which instruments the user switched off in the page: their notes are silent, and .midi() code newly aimed at them is refused until the user switches them on.

Searches the sound catalog of one instrument: a list of the model's sounds kept in the user's data folder, built from a patch-name file or a sound list the user owns. It finds sounds by words in the name or the category, in any order, with case and spaces ignored. It returns at most 25 matches: the exact name first, then names that start with the words, then names that contain them, then matches in the category only. Each match gives the name as the sound option of .midi() takes it, the program as sent (0-127), the bank when there is one, the category and, for an instrument whose model declares engines, the engine of the sound or that it is in no engine. It says how many more matched. A drum kit is marked (drum kit) and gives its drum map, or says the map is unknown.

Saves an instrument model that you drafted from a page of the instrument's manual the user pasted, into the user's Moontide data folder (models/.json), never into Moontide itself. First call it with confirmed: false: it checks the model and returns a summary (channels, sounds with their program numbers as sent and as numbered in a manual from 1, controls, reset bytes, notes) and saves nothing. Show that summary to the user, and call it again with the same model and confirmed: true only after they say yes. It refuses an id of a model Moontide ships, and an existing model unless overwrite is true. Fields: id (lowercase letters, digits, dashes or underscores, at most 32), name, channels { melodic, rhythm } (lists of channels 1-16), bankSelect (none, msb or msb-lsb), rhythmBank (optional: true when the instrument chooses drum kits by bank select and program change; every rhythm sound then needs a bank), drumMaps (optional, at most 8: [{ id, name, notes: [{ note 0-127, name }] }] typed from the instrument's manual), drumMap (optional: the id of the map of kits without their own; general-midi is built in), a rhythm sound's noteMap (optional: a map id, or null when no map is known for that kit), defaultVolume (0-127), clock (optional: true when the instrument follows MIDI clock, so Moontide sends it the clock, Start and Stop), monophonic (optional: true when the instrument plays one note at a time), reset (optional: sysex with at most 4 messages, each { kind: roland-dt1, model, address, data } as hex bytes or { kind: raw, bytes } from F0 to F7 and at most 32 bytes, and waitMs), controls ([{ id, name, cc, min, max, default }]), sounds { melodic, rhythm } ([{ name, program 0-127 as sent, bank { msb, lsb } when the instrument needs one }]) and notes (facts about the instrument, at most 10).

Saves a sound catalog that you drafted from a sound list the user gave you (for example the maker's PDF list), into the user's Moontide data folder (catalogs/.json), never into Moontide itself. The catalog extends the model named by model. Send the sounds grouped as the list prints them, at most 500 per call: the first call starts the draft (source, programNumbering, and overwrite when it replaces a catalog), later calls add parts with append: true, with more: true while parts remain. The last part checks the whole draft and returns a summary that shows three sounds with their program as sent and as numbered from 1, and saves nothing. Show that summary to the user, then call again with model and confirmed: true, and nothing else, only after they say yes. The draft lives only in this session; a restart of the server loses it. For a model whose rhythm channels take a bank, a group of drum kits takes role: rhythm and may give noteMap; its kits are saved in the catalog's kits list.

Switches how requests the user types in the Moontide page reach you. State on returns the command to run now with your Monitor tool, so each request arrives as soon as it is sent. State off says how to stop that monitor, after which requests wait on the Moontide server and arrive in the reply of your next other Moontide tool. Call it when the user asks, in any words, to turn page requests on or off, to take requests from the Moontide page right away, or to stop. The page-requests-on and page-requests-off prompts do the same where the client offers MCP prompts.

Starts Moontide: its web server on this computer and its page, which opens in a new browser tab; one click in that tab turns the sound on. Call it when the user asks, in any words, to start or open Moontide, or asks which tab or port is yours. Calling it again is safe: it gives the page address, the port and the tab title, and opens a new tab only when no page is connected. set_code starts Moontide by itself, and so does restore_version for a version that exists, so there is no need to call it before them. edit_code changes music that already plays and starts nothing. The start prompt does the same where the client offers MCP prompts.