Skip to main content
Glama

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

Mix and master stems

doseedo_mix

MIXING and MASTERING: each part levelled, panned, high-passed, given its depth on a shared reverb, and mastered to a loudness target — a WAV AND mixgraph, the mix as a document you edit. After doseedo_render_score pass from_job (its parts and the instruments they play are the stems); or stems: [{name, audio_url, instrument?}] (result links work as-is). An orchestra (strings / winds / brass / timpani / harp…) is SEATED by default (film-orchestral: violins left, low strings right, brass behind, each seat at its depth in a 2.3 s hall, written dynamics riding the faders); other stems get the blind default. style: film-orchestral, film-scoring-stage, concert-hall, film-epic-hybrid, cathedral-choral, classical-chamber, cartoon-studio, golden-age-cartoon, jazz-combo, ambient, country-pop, metal-modern, 1950s-mono, 1960s-lcr-pop, 1970s-analog-rock, 1970s-dub, 1980s-pop-gated, 1990s-rock-dry, 1990s-hiphop, lofi-hiphop, 2000s-loudness-rock, 2010s-edm, 2010s-trap, 2020s-pop, 2020s-hyperpop — an id or words ("dry 90s rock"). balance {part: dB} moves parts on top of the levelling (+3 brings a melody forward). Change the mix: edit the returned mixgraph — strips[] {stem, gain_db, pan, seat, chain, sends}, buses[] (verb = the hall), master.chain, automation [{target: "strips..gain_db", points: [[seconds, dB]…]}] for rides (dB off the strip's gain_db: 0 = as set, -60 mutes) — and call again with mix_job (this job_id) + only your edits (or the whole mixgraph + the same stems): rendered as written, rails reported, no credits. Then doseedo_session_from_stems {from_job, mix_job: } → the DAW project at this mix's levels and pans. TO PICTURE: dialogue (the VO; the music ducks under each line), music_offset_s (bar 1 on the picture), length_s (cut + end fade). Async: job_id → doseedo_wait_task (~15–90 s). Cancel: the plane has no stop for a running mix — it runs to completion (credits spent), the job ends as canceled and its output is discarded. Only a job still queued at the plane is refunded by the plane's own failure refund.

Input Schema

NameRequiredDescriptionDefault
duckNoHow the music sits under the dialogue: {vo_over_db (default 7 dB — a broadcast mix's 6–10), carve_db (default 3, at 1–4 kHz), max_db (default 12), include (default true; false = the music bed alone, ducked as if the voice played)}.
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>.
roomNoAn orchestra's room: "studio" (intimate scoring stage, ~1.2 s, close), "stage" (~1.8 s), "hall" (the default scoring hall, ~2.3 s), "cathedral" (~4 s, wet) — or 0..1 between them. Sets the decay, size and how wet every seat sits.
stemsNo[{name, audio_url, instrument?}] — the stems (≤ 32). instrument = the sound it plays (a doseedo_instruments id: "violin", "timpani", "harp"), which decides how it is mixed; without it the name decides.
styleNoA mix style: an id or words ("dry 90s rock"). Pick it for the picture — the default (film-orchestral, a 2.3 s scoring hall) suits film drama, not every orchestra: cartoon-studio = a cartoon / animation orchestra (a close, dry, wide scoring stage, punchy rides); golden-age-cartoon = a 1940s–50s cartoon (mono, small studio, tape); film-scoring-stage = intimate TV / documentary; concert-hall; film-epic-hybrid = trailer / action; cathedral-choral; classical-chamber; or jazz-combo, ambient, 1970s-analog-rock, 2020s-pop …
balanceNo{part name: dB in -12..12} — your balance on top of the levelling (and of the written dynamics a from_job reads).
mix_jobNoMCP: a doseedo_mix job_id to edit — its whole stored mix (every ride) is the base, mixgraph is applied on top, and its stems are reused when you pass no from_job / stems.
vintageNoA period medium over any style, after the mix: "tape" = 7.5 ips tape (saturation, wow and flutter, a low hiss); "shellac" = a 78 played back (mono, ~90 Hz–5.5 kHz with the reproducer's presence, a 1.3 Hz wow, surface noise that swishes once a turn, crackle). "none" takes a style's own medium off (golden-age-cartoon carries tape). Its node (master.chain type vintage: noise_db, crackle, hi_hz …) is editable in the returned mixgraph.
dialogueNoThe VO / dialogue on the picture's timeline (≤ 4): [{name?, audio_url}]. The music ducks under each line until the voice sits duck.vo_over_db over it, with a 1–4 kHz carve while it talks; the voice joins after the music's master chain. Report: output.dialogue.lines [{start_s, end_s, duck_db, vo_over_music_db}] as mixed.
dynamicsNoFader rides from written dynamics: {part name: [[onset_seconds, velocity 0-127], …]}. from_job fills it from the score (pp to ff ≈ 17 dB); pass {} for no rides.
from_jobNoMCP: a doseedo_render_score job_id — its parts are the stems, each with the instrument it plays, and each part's written dynamics (its mean velocity) set its balance.
length_sNoThe program's length (a :30 = 30; ≤ 600 s): the mix is cut there with end_fade_s (default 0.5 s); the room's tail never runs past it.
mixgraphNoAn edited mix — the mixgraph a doseedo_mix returned, changed — rendered against the same stems (from_job or stems). With mix_job: ONLY what you change (strips[] by stem, automation[] rides by target — points: [] removes one, buses[] by id, master) — the rest is that mix as stored. A mixgraph marked `partial` (its rides summarized) is refused without mix_job. Omit for a fresh mix.
end_fade_sNoWith length_s: the fade at the program's end (0–10 s, default 0.5).
target_lufsNoMaster loudness, -24..-6 LUFS (default: the style's — -18 for film-orchestral, -14 for the blind default). Met within ~0.3 LU (a loud target clips the shortest transients first); output.loudness says what landed, and why when short. With mix_job it re-masters the stored mix.
tonal_matchNoNudge the master toward professionally mixed orchestral references (default on for the orchestral styles). Its presence and air are judged only where the score is written loud (written_level), so a pp passage keeps its darkness.
dynamics_rideNoHow hard the written dynamics move the faders: 1 = default (pp to ff ≈ 17 dB), 0 = no rides, up to 1.5.
written_levelNo[[seconds, velocity], …] — the whole score's written level, the loudest part sounding, held until the next row (0 = nothing plays). The tonal match reads only the passages it writes loud (f and louder), so a pp passage keeps its darkness. from_job fills it.
music_offset_sNoWhere bar 1 of the music sits on the picture (seconds, ≤ 600; the program ≤ 600 s): every music stem — and its rides — starts this late; the dialogue does not move.
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.
dynamics_carriedNo{part name: top velocity} — parts whose stems already play their written level (a render part's dynamics_level receipt, up to its top_vel). Their rides count it: no doubled swing. from_job fills it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. 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"
      +}
  2. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations declare a non-read-only, open-world, non-idempotent mutation, and the description adds substantial context beyond them: async job_id with ~15–90 s waits, no stop for a running mix (credits spent, output discarded), refunds only for plane-queued failures, and 'no credits' for mixgraph edits. The idempotency_key note sits slightly at odds with idempotentHint=false, but it is an opt-in request key rather than a claim the tool is idempotent, so this is not a true contradiction.

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?

Purpose and stems sourcing are front-loaded, and nearly every clause carries information, but the single sprawling block with nested parentheticals and a 25-item style enumeration is hard to parse on first read. It is dense rather than padded, but the structure could be split into clearer segments.

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 21-parameter tool with no output schema, the description covers the asynchronous lifecycle, cancellation and refund semantics, what the returned mixgraph contains and how to edit it, and even names result fields such as output.loudness and output.dialogue.lines. An agent has what it needs to call this correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is already 100%, so the baseline would be 3, but the description adds real meaning: balance is dB on top of the levelling (+3 brings a melody forward), automation values are dB off the strip gain_db with 0 = as set and -60 = mute, mixgraph edits are partial against the stored mix, and target_lufs states the tolerance and clipping tradeoff.

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 opening states a specific verb pair and resource: each part levelled, panned, high-passed, reverbed, then mastered to a loudness target, returning a WAV plus an editable mixgraph. It also distinguishes itself from siblings by naming doseedo_render_score as the source of from_job and doseedo_session_from_stems as the downstream consumer.

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 gives explicit selection rules: use from_job after render_score, or pass stems directly; call again with mix_job plus only your edits to revise a mix; use dialogue/music_offset_s/length_s when mixing to picture. It also names the follow-on tools and the wait/cancel path.

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