Skip to main content
Glama

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

Tempo map from hit points

doseedo_tempo_map
Read-onlyIdempotent

Scoring to picture: turn HIT POINTS (a cut, an impact, the title card — as seconds from the cue start or SMPTE timecodes) into a TEMPO MAP that lands each hit exactly on a downbeat (or a beat / an eighth — per hit with hits[].land), staying near your tempo and inside bpm_range. A cue whose pace changes (she runs faster, then stops): give the hit where it changes a bpm, and the map moves to that tempo from there, every hit still landed. An AD or any cue that must hold ONE tempo: fixed_bpm: true (+ max_deviation_bpm, tolerance_ms) finds the tempo and the bar-1 offset (music_offset_s) landing the most hits, and says which ones it could not. Returns tempo_map [{beat, bpm}] to pass unchanged to doseedo_render_midi / doseedo_render_score / doseedo_session_from_stems, and hits[] with the beat, bar and beat-in-bar each hit lands on — write the accent, stinger or change there. Handles 23.976 / 24 / 25 / 29.97 (";" = drop-frame) / 30 / 50 / 59.94 / 60 fps timecode. Pure math: free, instant, no key needed.

Input Schema

NameRequiredDescriptionDefault
bpmYesThe cue's tempo (20–300) — the map stays as close to it as the hits allow.
fpsNoFrame rate of the timecodes: 23.976, 24, 25, 29.97, 30, 50, 59.94, 60.
hitsYesThe moments the music must land on: [{time_s} (seconds from the cue start) or {timecode: "01:00:12:08"} (film timecode, with fps and start_timecode), label?, land?, bpm?}] — land = THIS hit's landing ("downbeat", "beat" or "eighth"; default: the request's land), e.g. the big cuts on bar lines and a quick accent on an eighth. bpm = the tempo FROM this hit on, a new section (the chase at 160 from the cut where she starts running, back to 112 when she stops), until a later hit names another; the range around it scales with it. A bare number = {time_s}.
landNoLand hits on bar lines (default), on any beat, or on any eighth — the default for every hit without its own land.
start_sNoAlternative: the cue start in seconds of film time (informational when hits are time_s).
bpm_rangeNoAllowed tempo range [min, max] (default ±12 % of bpm).
fixed_bpmNoONE tempo for the whole cue (an ad, a song-form cue): the solver picks the tempo (within max_deviation_bpm of bpm; default exactly bpm) and where bar 1 sits (music_offset_s, default within the first bar; offset_range_s) so the most hits land within tolerance_ms (default 40). Hits it cannot land come back landed:false with nearest_beat — never an error.
tolerance_msNoSOFT hits (0–250 ms): a hit within this of the grid counts as landed, and one the grid can't reach is reported (landed:false), never refused. Every hit then carries error_ms; hit_rate = landed / all.
offset_range_sNofixed_bpm: where bar 1 may sit on the cue, [min, max] seconds (default [0, one bar]).
start_timecodeNoFilm timecode of the cue's first downbeat (bar 1); hit timecodes are measured from it.
time_signatureNoMeter (default 4/4).
max_deviation_bpmNoHow far the tempo may move from bpm (both modes; in place of bpm_range). A variable map at 124 ±12 % can swing 11+ bpm between hits — 3 keeps it a steady groove.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, but the description adds material context beyond them: it is pure math, free, instant, and needs no key, and it discloses that unlandable soft hits come back landed:false with nearest_beat rather than as an error. It also describes the returned tempo_map and hits shapes even though no output schema exists.

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 core purpose is front-loaded in the opening clause, and every sentence carries useful information about modes, outputs, or timecode handling. The description is dense and somewhat long for a single block, with several parenthetical examples, but it avoids true 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?

For a 12-parameter tool with no output schema, the description is complete enough: it covers the main scoring-to-picture use case, the fixed-tempo mode and its tolerance behavior, supported frame rates, and the returned tempo_map and hits arrays. It also identifies the downstream tools that consume the output.

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 baseline is 3, but the description adds interpretive meaning beyond the schema: a hit-level bpm means the tempo from that hit onward until another hit names a new tempo, and max_deviation_bpm is illustrated with a concrete example of 124 ±12% versus 3. It does not explain every parameter, but it meaningfully clarifies the interplay among hits[].land, hits[].bpm, fixed_bpm, tolerance_ms, and bpm_range.

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 gives a specific verb and resource — turn hit points into a tempo map that lands each hit on a downbeat, beat, or eighth — and distinguishes the output from downstream render tools by naming doseedo_render_midi, doseedo_render_score, and doseedo_session_from_stems. An agent can tell exactly what this tool produces.

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

Usage Guidelines4/5

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

It clearly frames the primary use case (scoring to picture) and gives concrete modes: variable tempo when the cue's pace changes and fixed_bpm: true for an ad or any cue that must hold one tempo. It names downstream consumers, but does not explicitly compare against sibling alternatives such as doseedo_score_to_picture or doseedo_spot_video.

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