Today a chart is generated from a single MIDI clip, producing a single-part score. A common need is a multi-instrument score: select several MIDI tracks (or clips) and render them together as a multi-staff score, each part with its own clef and transposition. MusicXML is already score-partwise, so the format supports this directly; the work is in the trigger, the payload/UI, and the score builder.
Desired behavior
- Select multiple MIDI tracks (or multiple clips) and choose "Show Chart" once.
- Each track becomes its own part in the score, with an independent instrument/transposition and an auto-detected clef.
- Parts share the chart's tempo, key, and time signature; bar lines align across staves.
Implementation notes
- Trigger / multi-select. The current context-menu action is registered on a single
MidiClip and receives one Handle (src/extension.ts:181, readClip at src/extension.ts:69). The SDK does expose multi-selection scopes: "ClipSlotSelection" passes { selected_clip_slots: Handle[] }, and the arrangement-selection scopes pass { selected_lanes: Handle[] }. Registering on one of these would let a single action receive clips/lanes across multiple tracks. Resolving each handle to its clip and track name follows the same path as readClip.
- Score builder is single-part.
notesToMusicXML (src/notation/musicxml.ts:149) emits exactly one <score-part id="P1"> and one <part id="P1"> (src/notation/musicxml.ts:184-185, 212). It needs to accept an array of parts and emit one <score-part> per instrument in <part-list>, then one <part> block each. The existing grand-staff path (two voices/staves within one part, src/notation/musicxml.ts:155-163) is a useful reference for multi-layer measure emission.
- Per-part settings. The payload (
src/payload.ts) and the webview UI currently model one instrument/clef/transposition. They would need to carry a list, one entry per selected track, with a sensible default per track and per-part clef auto-detection (reusing src/notation/clef.ts).
- Differing lengths. Tracks/clips of different lengths need padding to the longest part so measures align (the timeline already pads with trailing rests via
timelineToMeasures).
Open questions
- Track selection vs. clip selection: a track may have many clips. Start from a clip selection (
ClipSlotSelection), where the chosen clips are unambiguous?
- Part ordering (selection order vs. track order) and naming (track name as
<part-name>).
- How per-part transposition is presented in the UI without crowding it.
Today a chart is generated from a single MIDI clip, producing a single-part score. A common need is a multi-instrument score: select several MIDI tracks (or clips) and render them together as a multi-staff score, each part with its own clef and transposition. MusicXML is already
score-partwise, so the format supports this directly; the work is in the trigger, the payload/UI, and the score builder.Desired behavior
Implementation notes
MidiClipand receives oneHandle(src/extension.ts:181,readClipatsrc/extension.ts:69). The SDK does expose multi-selection scopes:"ClipSlotSelection"passes{ selected_clip_slots: Handle[] }, and the arrangement-selection scopes pass{ selected_lanes: Handle[] }. Registering on one of these would let a single action receive clips/lanes across multiple tracks. Resolving each handle to its clip and track name follows the same path asreadClip.notesToMusicXML(src/notation/musicxml.ts:149) emits exactly one<score-part id="P1">and one<part id="P1">(src/notation/musicxml.ts:184-185,212). It needs to accept an array of parts and emit one<score-part>per instrument in<part-list>, then one<part>block each. The existing grand-staff path (two voices/staves within one part,src/notation/musicxml.ts:155-163) is a useful reference for multi-layer measure emission.src/payload.ts) and the webview UI currently model one instrument/clef/transposition. They would need to carry a list, one entry per selected track, with a sensible default per track and per-part clef auto-detection (reusingsrc/notation/clef.ts).timelineToMeasures).Open questions
ClipSlotSelection), where the chosen clips are unambiguous?<part-name>).