Skip to main content
Glama

Doseedo Film Score: spot a video, play your score on AI instruments, mix it to picture

Mix and master stems

doseedo_mix

MIXING and MASTERING: mix the stems instead of summing them: each part levelled for how loud it plays, panned, high-passed, given its depth on a shared reverb, and mastered to a loudness target — returned as a WAV AND as 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, winds centre, brass behind, each seat with its own depth in a 2.3 s hall, written dynamics riding the faders; room / dynamics_ride change that); 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, 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 — and call again with mixgraph + the same from_job / stems — or mix_job (this job_id) + only your edits: rendered as written (safety rails apply, reported), no credits. report.strips..active_lufs = how loud each part plays in the mix. Then doseedo_session_from_stems {from_job, mix_job: } → the DAW project at this mix's levels and pans. 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
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.
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.
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.
target_lufsNoMaster loudness, -24..-6 LUFS (default: the style's — -18 for film-orchestral, -14 for the blind default).
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.
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. First observed

TDQS

A4.8/5.0
Behavior5/5

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

It discloses behavior well beyond the annotations: output includes WAV and mixgraph, edits through mix_job render as written with safety rails and no credits, and async jobs take roughly 15–90 s. It also gives unusually specific cancellation semantics — no stop for a running mix, credits spent, output discarded, only queued jobs refunded — without contradicting readOnlyHint=false or destructiveHint=false.

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 purpose and primary workflow are front-loaded, and the length is largely justified by the tool's 15 parameters and many edit pathways. It is dense and paragraph-like rather than sectioned, so scanability suffers slightly, but most sentences carry actionable information rather than filler.

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?

With no output schema, the description still explains the returned artifacts (WAV and mixgraph), key report fields such as report.strips.<part>.active_lufs, async job handling, and cancellation limitations. Given the complexity and rich input schema, an agent has enough context to invoke and follow up correctly.

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 coverage is 100%, so the schema already carries most parameter definitions. The description still adds cross-parameter workflow meaning for from_job, stems, mixgraph, and mix_job, and supplies the long style id list that the schema only partially exemplifies, though many individual parameter details remain schema-led.

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 and resource — mixing and mastering stems instead of summing them — and enumerates the concrete processing applied. It also names related tools and input modes, so an agent can distinguish this from rendering, stem separation, or session creation.

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?

The description gives explicit entry paths: use from_job after doseedo_render_score, or pass stems directly; then edit the returned mixgraph and call again with mix_job or with the same from_job/stems. It also routes the follow-on step to doseedo_session_from_stems and explains the async wait path with doseedo_wait_task.

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