Problem. feedBack-plugin-midi's midi_amp enumerates MIDI outputs and sends program/bank/kit changes through its own private plumbing. The sound timeline work (editor project #5, item C3) needs the same output path with per-device patch maps, intent.gm → device translation, and look-ahead pre-fire; future consumers include hardware vocal processors. Each consumer growing its own output enumeration is the same fragmentation midi-input (#309, #316, #318) exists to prevent on the input side.
Proposal (design-first, no implementation yet).
Process. Shared item (editor C3 ↔ Keys Foundations Ground): one issue, both boards. First deliverable is a domain spec reviewed with the midi-input owners; requirements input owed from the editor/midi_amp side.
Problem.
feedBack-plugin-midi'smidi_ampenumerates MIDI outputs and sends program/bank/kit changes through its own private plumbing. The sound timeline work (editor project #5, item C3) needs the same output path with per-device patch maps,intent.gm→ device translation, and look-ahead pre-fire; future consumers include hardware vocal processors. Each consumer growing its own output enumeration is the same fragmentationmidi-input(#309, #316, #318) exists to prevent on the input side.Proposal (design-first, no implementation yet).
midi-outputcapability domain, designed alongside — and shaped like — the in-flightmidi-inputcontrol plane ([Spec] midi-input control-plane capability domain (core-owned) #316), by the same owners. midi-control: narrow to mappings/CC routing (split from midi-input) #318 already splitmidi-control(mappings/CC routing) frommidi-input; this domain must slot into that map, not blur it.intent.gm→device translation) as data, consumed bymidi_amp; the plugin keeps the device-specific logic, core keeps enumeration/routing.Process. Shared item (editor C3 ↔ Keys Foundations Ground): one issue, both boards. First deliverable is a domain spec reviewed with the
midi-inputowners; requirements input owed from the editor/midi_ampside.