Depends on #54 (generation surface). Reads the per-deck beatgrid (M20, ADR-0014) and, when available, key (ADR-0024, currently Proposed).
Problem
A transition between two tracks is hand-built by a DJ from EQ, filters, and whatever risers they happen to own. LSDJai knows both decks' beatgrids (M20) and will know their keys (ADR-0024) — so it can generate a transition element (riser, sweep, impact, downlifter, noise wash) tailored to the exact moment: matched in length to the bars being crossed, optionally pitched to bridge deck A's key into deck B's. No normal DJ rig can do this; it is a generative-booth-native move.
Proposed approach
A "build transition" action that reads the outgoing/incoming decks' tempo (gated BPM, ADR-0010/0014) and key (when ADR-0024 lands), composes an SA3 prompt for the chosen transition type, requests a clip of exactly the bar-count being crossed, and drops it onto a free loop slot / one-shot to fire over the blend. Optionally seed it with a tail of deck A (init-audio, #54) so the riser grows out of the outgoing track. Honest about confidence (the ADR-0010 gate ethos): if tempo/key are ungated/unknown, fall back to a length-only request and say so — no false "key-matched" claim.
Acceptance criteria
- A user builds a transition element matched to the bars being crossed; it fires as a one-shot/layer over the blend and is audibly time-aligned.
- When BPM (and key, once ADR-0024 lands) are confident, the element matches them; when not, it falls back to length-only and the UI does not over-claim.
- Optional init-audio seeding makes the riser grow out of deck A's tail.
- Strings via i18n; house style;
npx tsc -p tsconfig.app.json --noEmit clean.
Scope & non-goals
In scope: on-demand transition generation tied to the two decks' grids. Non-goals: the plumbing (#54); automatic triggering of transitions (a performer fires them); building key detection itself (ADR-0024); a full automix.
Depends on #54 (generation surface). Reads the per-deck beatgrid (M20, ADR-0014) and, when available, key (ADR-0024, currently Proposed).
Problem
A transition between two tracks is hand-built by a DJ from EQ, filters, and whatever risers they happen to own. LSDJai knows both decks' beatgrids (M20) and will know their keys (ADR-0024) — so it can generate a transition element (riser, sweep, impact, downlifter, noise wash) tailored to the exact moment: matched in length to the bars being crossed, optionally pitched to bridge deck A's key into deck B's. No normal DJ rig can do this; it is a generative-booth-native move.
Proposed approach
A "build transition" action that reads the outgoing/incoming decks' tempo (gated BPM, ADR-0010/0014) and key (when ADR-0024 lands), composes an SA3 prompt for the chosen transition type, requests a clip of exactly the bar-count being crossed, and drops it onto a free loop slot / one-shot to fire over the blend. Optionally seed it with a tail of deck A (init-audio, #54) so the riser grows out of the outgoing track. Honest about confidence (the ADR-0010 gate ethos): if tempo/key are ungated/unknown, fall back to a length-only request and say so — no false "key-matched" claim.
Acceptance criteria
npx tsc -p tsconfig.app.json --noEmitclean.Scope & non-goals
In scope: on-demand transition generation tied to the two decks' grids. Non-goals: the plumbing (#54); automatic triggering of transitions (a performer fires them); building key detection itself (ADR-0024); a full automix.