Skip to main content
Glama

Doseedo: Film Scoring, AI Instruments, Sound Effects & Stems

Fill a gap in a recorded part

doseedo_fill_gap

INPAINT (repair) a part: send ONE recorded part (a stem, a DAW track's audio) with a gap in it — the silence between two clips, a bar to redo, a dropout — and get it back with the gap PLAYED: the take before and after the gap is kept bit-exact (spliced back), and the gap is generated against both, so it continues out of what comes before and leads into what follows. What fills it is planned first (the DSP plane's extend planner, which hears the part): the take's own LOOP when it has one — the gap is seeded from its own passes at the matching bar phase, so a groove keeps turning — else a part written in its key and over its chords, performed in the take's own sound. Pass the session's bpm and bar grid (bar_offset_seconds: where a bar line falls in the audio you send); the gap is in seconds of that audio. Send the part with some of the take on each side of the gap (8 bars or more before it is best). Async: job_id → doseedo_wait_task (~40–150 s) → takes[{url}]: WAVs as long as the audio you sent, the gap filled — cut out the gap (or the span you need) to drop it into the DAW. output.plan says what filled it (loop bars, or the writer and the changes). Cancel: a render that has not reached the GPU yet is stopped and its credits refunded; one already rendering finishes on the GPU (its credits are spent), the job ends as canceled and the output is discarded.

Input Schema

NameRequiredDescriptionDefault
bpmYesREQUIRED. The session's tempo — the gap is filled on its bar grid.
fillNoWhat fills the gap: "context" = the span played AGAIN from the take around it — no plan, no notes: a variation of what is there, in its own sound and level (INPAINTING a span that has audio — the right default there); "loop" = the take's own passes (a groove that keeps turning), "written" = a part written in its key and chords, "auto" (default) = the loop when the part has one, else written.
keepNofill "context": how much of what is in the span its regeneration keeps, 0.01–0.9 (default 0.05: a variation; 0.45 ≈ the same playing again).
nameNoOptional: a name for this job's files, e.g. "rainy-loop-3". Every file it returns downloads as <name>_<part>.<ext> (rainy-loop-3_Celesta.wav, rainy-loop-3_rough-mix.wav; one take: rainy-loop-3.wav), so the user can find them. Give each job its own name (a second take: "rainy-loop-3b"). Default: doseedo-<last 6 characters of the job id>.
roleNoThe part's role, when you know it (the planner hears it otherwise).
seedNoOptional random seed (the same seed plans and renders the same).
notesNoYOUR part for the gap — a custom part (a MIDI region drawn there in the DAW): [{pitch, start_seconds, duration_seconds, velocity?}], seconds of the audio you send. It is the written part, no planner: the take plays exactly these notes, in its own sound (notes outside the gap are ignored; silence where there are none). fill "written" or omitted. ≤2000.
takesNoHow many takes, 1–4 (default: the server's best-of-N).
audio_keyNoR2 ingest key of an uploaded audio file (from doseedo_get_upload_url / POST /api/upload/r2/ingest-url; starts with "ingest/"). The part, with the gap in it. Provide this or audio_url.
audio_urlNohttps URL of the audio, as an alternative to audio_key: a doseedo result URL exactly as a job returned it (a stem, a take, a bounce), or any public URL. The gateway fetches it (≤256 MB) into your account's ingest storage before the job starts. Pass audio_key OR audio_url.
exact_gridNotrue = the audio is cut from a DAW session, so bpm and bar_offset_seconds are its EXACT grid: the fill keeps it (default false: the planner fine-tunes the grid to the audio's own onsets — right for a stem whose tempo you only know roughly).
instrumentNoWhat plays the part (an id from doseedo_instruments). Optional — the take's own sound is kept either way; a written fill is played by it.
track_nameNoThe part's track name in the DAW ("Drums", "Bass", "Strings") — the planner hears a role from the name first, then from the sound.
time_signatureNoThe session's meter, e.g. "4/4" (default) or "3/4".
gap_end_secondsYesREQUIRED. Where the gap ends (and the take resumes), in seconds of the audio.
idempotency_keyNoOptional. Any unique string for THIS request (e.g. a UUID). Re-sending the same call with the same key after a timeout returns the same job instead of starting a second one.
duration_secondsYesREQUIRED. The audio's length in seconds (1–600).
gap_start_secondsYesREQUIRED. Where the gap starts, in seconds of the audio.
bar_offset_secondsNoWhere a bar line falls in the audio (seconds; default 0 = the audio starts on a downbeat). Sending a span of a DAW track that starts mid-bar? Give the first downbeat's time in it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / notes
      Added value: +{
      +  "description": "YOUR part for the gap — a custom part (a MIDI region drawn there in the DAW): [{pitch, start_seconds, duration_seconds, velocity?}], seconds of the audio you send. It is the written part, no planner: the take plays exactly these notes, in its own sound (notes outside the gap are ignored; silence where there are none). fill \"written\" or omitted. ≤2000.",
      +  "items": {
      +    "properties": {
      +      "duration_seconds": {
      +        "type": "number"
      +      },
      +      "pitch": {
      +        "type": "number"
      +      },
      +      "start_seconds": {
      +        "type": "number"
      +      },
      +      "velocity": {
      +        "type": "number"
      +      }
      +    },
      +    "required": [
      +      "pitch",
      +      "start_seconds",
      +      "duration_seconds"
      +    ],
      +    "type": "object"
      +  },
      +  "type": "array"
      +}
  2. Changed1 schema field changed
    • addedInput schema / properties / name
      Added value: +{
      +  "description": "Optional: a name for this job's files, e.g. \"rainy-loop-3\". Every file it returns downloads as <name>_<part>.<ext> (rainy-loop-3_Celesta.wav, rainy-loop-3_rough-mix.wav; one take: rainy-loop-3.wav), so the user can find them. Give each job its own name (a second take: \"rainy-loop-3b\"). Default: doseedo-<last 6 characters of the job id>.",
      +  "maxLength": 80,
      +  "type": "string"
      +}
  3. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations declare readOnlyHint=false, openWorldHint=true, idempotentHint=false, and destructiveHint=false, so the safety profile is partly covered. The description adds substantial context beyond that: the async job lifecycle, ~40–150 s render time, bit-exact splicing of surrounding audio, the output.plan field, and precise cancel/refund behavior. It does not contradict any annotation.

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 long and dense, but it is front-loaded with the core operation and the length is justified by a 19-parameter tool with a multi-step async workflow. Heavy capitalization and parenthetical asides add some noise, but every section carries operational information.

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 complex, async, 19-parameter tool with no output schema, the description covers the full lifecycle: input requirements, planning behavior, return shape (takes[{url}], output.plan), timing, and cancellation. An agent has everything needed to invoke it correctly and interpret the result.

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 description coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema: it explains that the gap is in seconds of the audio sent, that bar_offset_seconds marks where a bar line falls, and that bpm/bar grid drive the fill. It also clarifies the practical requirement of including take audio on each side of the gap.

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 ('INPAINT (repair) a part') and immediately defines the operation: send one recorded part with a gap, get it back with the gap played. It clearly distinguishes this from generative siblings like doseedo_generate_music or doseedo_render_midi by emphasizing that the surrounding take is kept bit-exact and the fill is generated against it.

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 states exactly when to use each fill mode ('context' for inpainting a span that has audio, 'loop' for a groove, 'written' for a composed part, 'auto' as default), gives practical guidance ('send 8 bars or more before it is best'), and spells out the async workflow via doseedo_wait_task with expected timing. Cancel semantics are also documented, leaving little to inference.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources