Skip to main content
Glama

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

Audio → DAW session

doseedo_audio_to_session

Turn an uploaded full mix into a complete multitrack DAW session (separated stems as tracks, tempo map, optional per-stem MIDI and chord guide). The result is a downloadable session zip for Logic Pro or Ableton. Async: returns a job_id — poll with doseedo_wait_task (~4 minutes). Cancel: cooperative — the build stops at its next stage boundary and the build's sound-tool unit is refunded (a GPU separation already run stays charged).

Input Schema

NameRequiredDescriptionDefault
keyNoDetect the key and write it into the project (default true in the full build, false with simple).
nameNoProject name for the session file — it also names the download: <name>_session.zip.
loopsNoDetect repeated clips and lay them as loops (default false).
chordsNoAdd a detected-chords guide track (default false).
retuneNoDefault true: a mix sitting >35 cents off A440 is pitch-corrected onto the 12-TET grid before separation (every transcriber coin-flips otherwise). false = leave the tuning as recorded.
simpleNoFaster minimal build: meter + tempo + stems only, no MIDI (default false). Required for stem_mode orchestra/detect.
targetNoDAW target (default logic).
markersNoAdd section markers (intro/verse/chorus…) (default true in the full build, false with simple).
dereverbNoOpt-in: lay DRY stems and recreate the room with a reverb plugin on each track (default false).
separateNofalse = no separation: the mix lands as ONE audio track (default true).
audio_keyNoR2 ingest key of an uploaded audio file (from doseedo_get_upload_url / POST /api/upload/r2/ingest-url; starts with "ingest/"). 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.
stem_modeNoSeparation family. auto (DEFAULT): the 6 stems plus a residual cascade that peels detected orchestral sections out of "other" (no orchestral content → identical to 6stem). 6stem: vocals/drums/bass/guitar/piano/other. drumsep: the drum stem replaced by isolated kick/snare/hh/… tracks on a Drums bus. sections: the 6 stems with "other" split by the joint section model (trumpet/trombone/sax/violin/viola/cello), each transcribed per chair. orchestra / detect: the 53-instrument bank on the MIX (needs simple:true; detect auto-picks, orchestra takes `instruments`).
tempo_mapNofalse = one constant tempo instead of a tempo map (default true).
midi_stemsNoOptional comma-separated stems to also add as MIDI tracks, e.g. "piano,bass" (include "drums" for a GM drum roll).
instrumentsNostem_mode orchestra/detect: optional comma list restricting the orchestral set, e.g. "violin,cello,flute".
crop_silenceNoPunch regions in where each stem plays instead of whole-length stems (default false).
drum_samplerNoSampled kits → a one-shot sampler track + MIDI (default false).
guitar_splitNoSplit the guitar stem into N players, each its own track + MIDI lane on a Guitar Section bus: "0" (off), "auto" (DEFAULT — a one-vs-two probe decides), "2"–"4".
drum_substemsNoLay each drum piece as its own audio track on a Drums bus (default false; implied by stem_mode drumsep).
quantize_midiNoSnap every pitched MIDI lane: "grid" = to the grid its own onsets support (straight/swing 8ths, 16ths, triplets, detected per lane); "score" = notation positions (straight 8ths). Default off (played timing).
drum_midi_splitNoWith "drums" in midi_stems: one Quick Sampler track PER kit piece, each loaded with a synthesized one-shot (default false = one GM drum-roll track).
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.
keep_stem_audioNoWith midi_stems: keep the audio stem next to its MIDI track (default true); false = the MIDI track REPLACES the audio.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / name / description
      Previous value: -"Project name for the session file."New value: +"Project name for the session file — it also names the download: <name>_session.zip."
  2. First observed

TDQS

A4.1/5.0
Behavior5/5

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

Annotations already disclose readOnly=false, openWorld=true, idempotent=false, destructive=false; the description goes further by explaining the async job_id flow, approximate runtime, downloadable session-zip result, and cooperative cancellation with partial refund/charge behavior. That is exactly the kind of operational context annotations cannot express, with no contradiction.

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

Conciseness5/5

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

Four sentences, front-loaded with the output and then the async/cancel mechanics; no filler. Every sentence contributes either the deliverable, the polling instruction, or cancellation/refund behavior.

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 24-parameter tool with no output schema but complete schema descriptions and annotations, the description covers the essential contract: input is a full mix, output is a session zip, execution is async, and cancellation has billing consequences. It is complete enough for correct invocation, even though sibling differentiation remains implicit.

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 coverage is 100% and the schema descriptions are highly detailed, so the baseline is 3; the description only summarizes the output (stems, tempo map, MIDI, chords) and does not add syntax or default semantics beyond the input schema. No parameter-specific guidance is needed here, but none is added.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: turns an uploaded full mix into a complete multitrack DAW session, and lists the delivered artifacts (stems, tempo map, optional MIDI/chord guide) plus the downloadable zip. It does not distinguish this from siblings such as doseedo_session_from_stems or doseedo_separate_stems, so an agent must infer when this full-build path is preferable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives operational guidance for the async job (poll with doseedo_wait_task, ~4 minutes) and cancellation semantics, but never states when to use this tool instead of related siblings (e.g., already-separated stems vs. a full mix, or stems-only workflows). Usage is implied by 'uploaded full mix' but not explicitly scoped with exclusions.

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