2026-07-28 - Automation Doorway Label Parity

The customer-facing docs and help text should name both visible automation doors exactly as the user sees them: Arrangement uses the compact AUTO label to preserve toolbar space, while Piano Roll uses the clearer AUTOMATION label. Both open the same Automation editor and both may show a +N suffix when rows already exist for the resolved target.

2026-07-24 - Arrangement Automation Doorway

AUTO is the compact visible Arrangement doorway for Automation. It lives in the main Arrangement toolbar beside snap/cut/render controls, while the lane Signal panel remains the alternate per-lane doorway. Opening it targets the selected clip first, then the real clip under the Arrangement playhead, then the first real clip in the selected lane. Section markers do not own MIDI automation. The AUTO +N suffix reports existing Automation rows for the current target.

2026-07-26 - Multi-Controller Live Input Diagnostics

MIDI Health should distinguish queue latency from source ambiguity. If multiple physical MIDI inputs are open, or if more than one controller has actually sent musical MIDI into an unpinned live route, the directInput diagnostic row should show the device IDs and offer a safe navigation action to MIDI Hardware. The recommendation is to pin the armed lane to one input device, split controllers by MIDI channel, or deliberately accept layered input. The action sends no MIDI and mutates no project state.

2026-07-17 - Automation Doorway Names

Arrangement automation should be described with the same words the user sees on screen: the compact toolbar doorway is AUTO, the full feature name is Automation, and the ownership choice happens inside the editor as Shared PTN, Clip Local, or Lane Local. Older Arrangement automation badge names are obsolete and should not appear in customer-facing instructions.

2026-07-15 - Automation QA Receipt Workflow (Hardened)

1. Open MIDI Health and enter the Automation closeout action.
2. Use one exact musical context and record its Pattern, Clip, and Lane numbers.
3. Verify every required doorway reaches that context.
4. Repeat edit, Undo/Redo, playback, and export checks under Shared PTN, Clip Local, and Lane Local ownership.
5. Confirm Shared PTN affects linked clips, Clip Local isolates one clip, and Lane Local follows the lane.
6. Save PASS only with ALL REQUIRED DOORWAYS, ALL OWNERS, and ALL OWNERS VERIFIED.
7. Use FAIL or BLOCKED for an early stop and preserve the exact observation rather than claiming unperformed checks.

MIDI Health displays one-based numbers to the musician and stores exact zero-based indices. The receipt is cold project evidence: it sends no MIDI and changes no hardware.

2026-07-15 - Automation QA Receipt Workflow

1. Open MIDI Health and use the closeout action to reach Automation.
2. Exercise the intended doorway and owner: Shared PTN, Clip Local, or Lane Local.
3. Verify editing, Undo, playback, and Arrangement export against the exact clip/PTN/lane target.
4. Return to MIDI Health and choose SAVE QA.
5. For PASS, select the doorway and owner, enter the exact target, confirm the complete workflow, and choose the ownership proof matching that owner.
6. Add evidence notes and screenshot/log references, then save to the append-only project ledger.
7. Use FAIL or BLOCKED when the workflow stops early; describe the observed failure instead of checking steps that did not happen.

The form sends no MIDI and changes no hardware. It records cold project evidence only.

2026-07-15 - Hardware Passport SysEx Policy UX

A Hardware Passport may enable automatic restore-response handling only for a policy that SpaceAge actually implements and only for that policy's exact message family. At launch, the automatic path is limited to standard MIDI Sample Dump data packets. Unknown or future Yamaha/Roland/vendor policy IDs must display as unsupported/manual verification; they must not silently inherit behavior from a manufacturer name or byte. Customer reports should expose dialect, exact family, checksum policy, and whether correlation is automatic or manual.

2026-07-15 - SysEx Restore Response UX Contract

The SysEx Vault may show hardware ACK, rejection, wait, or cancel evidence only when the response can be correlated to exactly one outgoing restore. For MIDI Sample Dump Standard transfers this means an outgoing SDS data packet plus matching device id, packet number, and selected input source. If the response belongs to the wrong device or packet, the outgoing payload uses another dialect, or multiple active attempts could claim it, SpaceAge must keep waiting and present the response as unrelated/ambiguous review evidence rather than success. Vendor-specific Hardware Passports must remain manual-review or manual-verification workflows until their exact response dialect and checksum/address rules are declared and tested.

2026-07-14 - Current Automation Ownership Workflow

Automation is an owner-scoped MIDI performance automation editor. The owner selector offers Shared PTN, Clip Local, and Lane Local when the current Arrangement context provides those identities. Shared PTN is reusable pattern automation and keeps the VARIANT / ACK SHARED guard when linked clips would all change. Clip Local follows one Arrangement clip. Lane Local follows the lane and layers across its clips. Playback and export use Shared PTN -> Lane Local -> Clip Local precedence. View and fit commands change only the viewport, never ownership.

2026-07-13 16:25 - Settings MIDI Panel Readability Rule

• MIDI Settings panels should expose the next useful action on-screen and push exhaustive forensic detail into COPY REPORT. Hardware setup cards show a compact checklist preview; selected scenarios and copied reports carry the long form.

2026-07-13 - REC wording rule: describe recording as Arrangement lane + playhead owned. Selection is editing context, not a hidden recording destination.

SpaceAge MIDI UI Workflow Spec

Last updated: 2026-07-17

This spec describes the customer-facing MIDI workflows SpaceAge should present as MIDI support moves through launch closeout. It is written from the user's point of view first, while staying aligned with the current MIDI architecture: lane-owned routing, project-persistent control mappings, explicit Hardware Passports, and SysEx actions that never happen silently.

Product Promise

MIDI in SpaceAge should feel powerful without feeling like a protocol editor. The user should be able to plug in a controller, assign knobs, import a file, route lanes, preserve expressive data, and recall hardware with clear previews and no hidden sends.

2026-07-13 expression receipt extension: Expression/automation recording receipts obey the same committed-state rule as note and drum recording. A recorded CC, pitch-bend, pressure, or other editable expression event should refresh Automation and report as expression/automation context only after the event has landed in the pattern event list. It must clear stale note/drum receipt fields so the status area does not re-report the previous musical note when the new capture was automation.

2026-07-13 receipt rule: Recording receipts should be sourced from committed recording state, not from the first queue/enqueue gesture. Melodic receipts should name the committed note, step, length, velocity, and channel context. Drum receipts should name the committed pad label, pad number, step, and velocity. If the event is not a note/step capture, the UI may report AUTOMATION EVENT, but drum note-on capture should never hide behind that fallback once the committed pad/step data is available.

2026-07-12 visibility note: MIDI SETUP should surface hardware editor readiness directly in the selected-template callout and copied preview report. If a Yamaha XG, Roland GS, GM module, or device-specific editor is not verified yet, the user should see that it is locked until the exact manual/Data List, address map, checksum policy, range labels, and queue-safety behavior are proven.

Core principles:

• Show the musical result before the raw MIDI detail.
• Keep input, playback, export, and hardware recall visibly separate.
• Make advanced MIDI data inspectable instead of surprising.
• Never send SysEx, bank changes, program changes, clock, transport, or raw thru data without an explicit user action.
• Use the same labels everywhere: MIDI IN, INPUT CH, PLAY/EXPORT CH, Hardware Passport, Expression Lane, and SysEx Vault.

Entry Points

The MIDI workflow should be reachable from several natural places:

• A learn button or context menu on any learnable control.
• A MIDI Assignments browser from the settings or MIDI toolbar area.
• A Lane MIDI Routing card inside each Arrangement Lane.
• A Create Hardware Passport From This Lane lane action.
• A Hardware Passports / SysEx Vault panel for external gear.
• A MIDI Import Wizard when opening or dragging in .mid files.
• Expression lanes inside the Piano Roll or clip editor.
• Safety confirmation dialogs before any hardware-affecting action.

These entry points should reuse shared assignment summaries, routing labels, and validation warnings so the same MIDI state does not look different in different panels.

MIDI Learn must keep the preflight/confirmation pattern. When a moved hardware source already controls another target, the MIDI Maps panel should pause the capture and present three choices: REPLACE for "this knob belongs to the new target now," MACRO for "this knob should control both/all targets," and CANCEL for "I moved the wrong thing." The confirmation UI should always name the incoming source, the new target, and the older targets before committing. Silent replacement is forbidden because it destroys performance mappings; silent macro creation is also forbidden because it can make one hardware gesture move hidden destinations.

The MIDI SETUP guide should render spaceage::midi::buildMidiHardwareSetupScenarios() as its source of truth. That model currently covers controller input, one external synth, multitimbral modules, MIDI guitar, wind controllers, and drum pads. Future wizard buttons should grow out of those scenario records rather than duplicating the setup prose, because the same scenario flags can drive Hardware Passport creation, channel templates, timing calibration prompts, expression-lane defaults, and hardware safety warnings.

Scenario records may name common hardware families to reduce abstraction. Example labels such as MiniNova, QY-70/QY-100, EWI, MIDI guitar systems, and MPC-style pads are descriptive guide copy, not device-detection promises. A first backend MidiHardwareSetupDeviceTemplate layer now turns several of those examples into searchable setup templates. Template application must still show the concrete channel, bend-range, SysEx, timing, and routing choices before committing anything.

Device templates are allowed to know practical hardware expectations: MiniNova-style single-synth routing, QY/XG channel stacks, General MIDI channel-10 drum convention, EWI breath mapping, MIDI guitar per-string channel risks, and MPC-style pad learn. They are not allowed to send MIDI, arm lanes, or rewrite routing by themselves. The current UI treats them as a pre-filled checklist plus explanation; confirmed APPLY DRAFT is the project-only mutation boundary for creating or attaching a Hardware Passport draft. Hardware sends stay in separate test/recall actions.

Yamaha XG and Roland GS editor profiles must be manual-backed. Templates can draft routing, channel, Passport, and test-note setup, but deep edit pages such as Voice Select, Parts Mixer, Drum Map, Effects, System, and Librarian should remain profile-disabled until the exact Data List / MIDI Implementation rows have been mapped to CC, RPN, NRPN, SysEx address, value range, checksum, labels, defaults, and safety class. A QY/CBX/MU/Sound Canvas template is therefore not the editor itself; it is the safe doorway into building one.

Device templates now expose that editor readiness as structured data instead of only prose. Future Hardware Passport or Instrument Bay hardware panels should read hardwareEditorProfileLabel, hardwareEditorProfileState, hardwareEditorProfileSourceHint, hardwareEditorProfileChecklist, and deepHardwareEditorReady. If deepHardwareEditorReady is false, the editor may show disabled pages, documentation prompts, manual-import checklists, and safe common MIDI routing controls, but it must not queue device-specific SysEx or NRPN parameter sends.

MidiHardwareSetupDeviceTemplate::hookupChecklist is the source of truth for the practical "plug this into that, set this channel, send this test note" language. Template detail views, copied template reports, setup wizard previews, and future onboarding/manual pages should quote that checklist instead of writing parallel hookup instructions in PluginEditor or static docs. The checklist may suggest safe next actions, but it must remain read-only until the user chooses an explicit apply/test/recall action.

The MIDI SETUP popup now renders buildMidiHardwareSetupAssistantPlan() rows as live readiness cards. Users can select one scenario card and see a focused selected-scenario strip that summarizes the first actionable step before pressing NEXT ACTION. The action opens the safest existing destination for the first incomplete step: MIDI Input, MIDI Out, Hardware Passports, MIDI Timing, MIDI Health, MIDI Patch/Import Review, SysEx Vault, or Automation. This navigation action does not arm lanes, create Hardware Passports, attach hardware, send test notes, transmit SysEx, or rewrite project data by itself. Separate buttons such as APPLY DRAFT, UNDO DRAFT, and TEST NOTE are explicit project/write/send actions and must keep their own confirmations and receipts.

The primary input and output rows in each setup plan should quote the shared MidiInputTrustGateReport and MidiExternalOutputTrustGateReport summaries. MIDI Health, focused preflight popups, NEXT ACTION, and COPY GUIDE should therefore agree on whether MIDI IN and MIDI OUT are ready, idle, or blocked before the user starts chasing lower-level details.

The selected-scenario strip now includes a Device Template picker from buildMidiHardwareSetupDeviceTemplates(). Scenario selection should choose the nearest matching template, and manual template browsing should update the visible template focus details. COPY PREVIEW should copy the selected model-owned template preview report, including the current target-lane choice and diff.

Template preview/apply must use buildMidiHardwareSetupDeviceTemplatePreview() before any mutation. The preview should show proposed actions, lane changes, channel changes, Automation rows, Hardware Passport changes, timing-calibration prompts, warnings, and the blocked-until-apply list. The preview itself must keep wouldSendMidi false and should never create lanes, attach Hardware Passports, arm input, rewrite channel filters, or send test notes.

The current MIDI SETUP popup renders a compact version of that preview in the selected-scenario strip: a "will propose" side, a "blocked until apply" side, and a no-MIDI-sent header. It now also exposes a deliberately named APPLY DRAFT action. That wording matters: the button is a guarded project-only mutation after explicit confirmation. It can create or attach a Hardware Passport draft and lane channel/routing draft, but it does not send test notes, Program Change, Bank Select, MIDI Clock, transport, or SysEx.

Safe test notes should use buildMidiHardwareSetupTestNotePlan() before confirmation and MidiHardwareSetupTestNoteReceipt after the queue attempt. The plan is the customer-facing preflight for "are we ready to hear the hardware?" It must show missing output/Hardware Passport facts, the selected channel, note number, velocity, duration, preconditions, warnings, and the fact that building the plan sends no MIDI. The receipt must then say whether note-on and note-off were queued, which output device was targeted, which warnings remain, and which setup families were deliberately not sent.

The current MIDI SETUP popup exposes this as TEST NOTE, intentionally separate from APPLY DRAFT. It builds the lane-aware plan, changes to TEST BLOCKED when the route is incomplete, shows blocked reasons, and only after confirmation queues a note-on/note-off pair. COPY PREVIEW becomes COPY RECEIPT after a test attempt so support can see exactly what happened. Do not add Program Change, Bank Select, MIDI Clock, transport, SysEx, reset, template-apply messages, or timing calibration to this action. Test-note should feel like a safe handshake with the external device, not a hidden setup dump.

The first transaction-plan model for that guarded draft button is buildMidiHardwareSetupDeviceTemplateApplyTransactionPlan(). It translates a preview into project-side mutation steps, undo safety steps, and blocked hardware-send steps. The visible button must remain named APPLY DRAFT until the broader setup wizard can create lane stacks, Automation rows, timing prompts, and hardware-send choices from one reviewed diff. Hardware sends must remain outside that project-side transaction as separate test/recall actions.

The matching receipt shape is buildMidiHardwareSetupDeviceTemplateDryRunReceipt(). The model helper can still report a pure dry run, while the processor-owned draft apply helper returns the same receipt type populated with actual project-side changes, Undo/rollback availability, blocked hardware sends, follow-up actions, and warnings. Every receipt must keep proving that hardware sends stayed outside the project-side transaction.

The first processor-owned project draft helper is applyMidiHardwareSetupDeviceTemplateProjectDraft(). It requires explicit confirmation, creates a Hardware Passport draft, can attach that draft to one selected lane, and can set the lane's PLAY/EXPORT MIDI channel from the template. The MIDI SETUP panel now asks for the target explicitly: Passport only, the currently selected Arrangement lane by default, the armed input lane as fallback, or another reported lane. The helper creates a normal project checkpoint and a processor-owned rollback snapshot, and the UI exposes UNDO DRAFT beside the apply receipt.

The companion diff helper is buildMidiHardwareSetupDeviceTemplateProjectDraftDiff(). The UI calls this helper for the chosen target and shows/copies its before/after rows: current lane, current Hardware Passport, current PLAY/EXPORT channel, proposed Hardware Passport draft, proposed channel, blocked hardware sends, and undo status. If a future diff ever reports willSendHardwareMidi = true in a customer-facing apply path, keep the button disabled or route the user through a separate hardware-send confirmation phase.

Each setup scenario also carries channel-template, expression-template, hardware-template, and future-automation hint fields. The current guide shows those as read-only expectations; the future setup wizard should consume the same fields when it offers lane-arm, per-string, wind-controller, multitimbral, pad-learn, Hardware Passport creation, and timing-calibration shortcuts.

The same popup now exposes direct hub buttons for MIDI Input, MIDI Out, Hardware Passports, MIDI Timing, MIDI Patch/Import Review, SysEx Vault, and Automation. These are navigation shortcuts only. They exist because advanced MIDI users often know exactly which surface they need after reading a setup card, and making them close the popup to hunt for the matching button would violate SpaceAge's "keep the idea alive" principle.

The COPY GUIDE action should use midiHardwareSetupAssistantPlansToPlainTextReport() and append midiHardwareSetupDeviceTemplatesToPlainTextReport(). Each selected scenario plan and device template owns its plain-text report, and the guide report is a composition of those model reports. Do not rebuild setup-guide prose in the editor; the same text should be available to tests, future support bundles, and future in-app help.

The next UI step is a focused assistant view for the selected scenario. That view should enlarge the chosen checklist, show each incomplete step as a row with its own guarded action button, and keep the same non-mutating promise until the user explicitly chooses a write/send operation.

MIDI file import must show song metadata as a deliberate policy choice. The current Import Wizard exposes Keep project tempo/key, Review only, Adopt first tempo/key, and Review maps only as explicit choices. Imported tempo, meter, and key rows are reviewed and reported by the receipt; full map rows are carried in the apply receipt when map review is selected; first source tempo/key adoption now mutates through the processor apply path, while source meter and full tempo/key maps remain warnings/review intent until the project-level timeline-map mutation path is undo-safe. Dragging in a .mid file must never silently rewrite the song.

Automation / MIDI Expression Editing

The Automation panel is the owner-scoped MIDI automation/expression workbench. It can edit Shared PTN, Clip Local, or Lane Local data and can inspect rows, copy a report, add points at the playhead, draw ramps or direct scope shapes, erase snapped steps, quantize, nudge, thin, delete, select, drag, copy, cut, paste, and undo through guarded processor helpers.

The Piano Roll reserves a visible Automation strip below the chord lane. It previews effective automation for the visible musical context, explains the empty state, and opens the owner-scoped editor. The top-row AUTO button shows AUTO for an empty context and AUTO +N when effective rows exist. Every doorway must open the same context and preserve the selected owner; ownership belongs in the status strip and Source View rather than being hardcoded into the button name.

The Arrangement lane doorway uses the stable label AUTO, regardless of row count. Counts belong in tooltips, status copy, reports, and the editor itself, not in the lane command label. Tiny in-clip evidence badges may still use compact AUTO / A# shorthand because they are visual breadcrumbs inside clips, not primary lane commands.

Lane-level Automation opening should target the clearest musical context available. The order is: selected clip in that lane, clip under the Arrangement playhead, then first playable clip in the lane as a fallback. The UI should synchronize the selected clip and report whether it used selected clip, clip under playhead, or first clip in lane before opening the editor.

Expression data has three explicit owners: Shared PTN, Clip Local, and Lane Local. Keep the ACK SHARED / VARIANT guard visible only for Shared PTN edits that affect linked clips. The owner selector and status copy must name the current owner before editing.

VARIANT is the current approved independence workflow for automation. It copies the selected clip's pattern payload into a new pattern, including notes, chord markers, pattern length, and shared PTN MIDI automation. The resulting clip can then be edited without changing other linked uses of the original pattern. This is not the same as clip-local automation; it is a pattern-copy workflow that preserves musical content while breaking the shared reference.

The Automation editor should prefer consequence-first copy over protocol-first copy. SHARED PTN DATA is clearer than PATTERN-OWNED when the risk is that linked clips will also change. SOURCE VIEW and FIT SOURCE are viewport tools only; they focus the selected clip's source range but do not create a private automation layer.

Automation Ownership Architecture

The ownership architecture is implemented around three explicit promises. Shared PTN remains reusable pattern automation. Clip Local isolates one Arrangement clip. Lane Local follows the instrument lane over time. The owner selector must be visible before edits, Shared PTN keeps the linked-pattern guard, and playback/export layer Shared PTN, then Lane Local, then Clip Local.

Clip Local uses stable clip identity, separate from pattern number and lane index. Its data persists with the clip and remains isolated from linked uses of the same pattern. Copy/paste, split, resize, duplicate, archive, export-review, undo/redo, and deleted-gap restore behavior must preserve or deliberately transform that identity rather than silently changing ownership.

Lane Local belongs to the instrument lane over time rather than a repeating musical clip. It survives clip replacement and follows lane reorder/rename and channel-strip reassignment. General non-MIDI lane automation, effect gestures, and Motion Clips remain later architecture; the implemented owner currently governs MIDI performance automation.

Customer-facing labels must name the active ownership mode before editing. Doorways may remain compact as AUTO, but the owner selector, status strip, Source View, reports, and QA receipts must agree on Shared PTN, Clip Local, or Lane Local. Launch proof still requires hands-on isolation/layering, Undo/Redo, playback, and export receipts for all three owners.

The Automation copy report uses midiExpressionPreflightToPlainTextReport() with the current ownership label. Expression rows can include performance data, protected setup leftovers, and note-specific poly-aftertouch; the model layer owns the editable/review-only and ownership language so the editor, support bundles, setup assistants, coverage dashboard, and QA receipts quote the same facts.

The step-local clear action is intentionally surgical. A user who records one bad sustain-pedal point, pitch bend blip, breath bump, or aftertouch point should not have to delete an entire row. It must stay scoped to the selected Automation row and the current step range, and it must continue to refuse review-only setup data such as bank/program/RPN/NRPN/Data Entry rows.

Future piano-roll-style Automation rows should keep these same meanings: row selection chooses the target controller/pressure/bend row, the playhead defines local edits, setup data remains review-only unless routed through MIDI PATCH, and every destructive edit must pass through processor helpers so undo, sorting, pattern length, and timeline-expression filtering remain consistent.

MIDI Health / MIDI Dashboard

The MIDI Health view should be the user's plain-language overview of the project's MIDI condition. It should answer:

• Which lane is armed for live MIDI input?
• Which lanes have routing warnings?
• How many controller assignments exist, and are any unresolved?
• How many Hardware Passports and SysEx Vault snapshots exist?
• Is there hidden expression data such as pitch bend, pressure, program/bank, or CC lanes?
• Are there any hardware actions that need explicit review before playback, export, or collaboration?
• Did any safe runtime MIDI queue drop data during a dense controller stream, SysEx capture, or live recording pass?

The backend source of truth should be MidiProjectHealthSummary, built by CinematicDrumsAudioProcessor::buildMidiProjectHealthSummary(). The UI should render this aggregate rather than walking lanes, Hardware Passports, mappings, SysEx snapshots, and expression payloads independently.

The Health view should use deviceRepairRecommendations as the shared "next step" model. Each recommendation includes a plain-language action label plus structured action metadata (actionKind, target id, and lane index), so buttons can open the exact lane MIDI input, lane output, Hardware Passport, output setup, device refresh, or health surface that owns the repair.

Focused MIDI Input and MIDI Out panels should reuse the same recommendation model and button behavior. MIDI Health is the overview, but a user who opens the smaller Input or Output workbench should not lose the guided path. These buttons navigate to the repair surface only; they do not arm lanes, change output devices, attach Hardware Passports, send recall data, or rewrite project routing.

MIDI Input repair rows should include observed-channel mismatches. If SpaceAge recently heard CH 01 while the armed lane accepts CH 09, the focused panel should explain that the controller is visible but filtered out, then open the armed lane's MIDI input settings. The first customer-facing action remains navigation only; future explicit fixes can offer Omni, match observed channel, or controller-side guidance.

Focused MIDI Input and MIDI Out panels should also have their own COPY REPORT actions. These reports should compose the model-owned readiness/runtime/device inventory reports plus midiDeviceRepairRecommendationsToPlainTextReport() so a user can copy the smaller truth from the panel they are already looking at.

Implementation note: focused preflight reports should be composed by MIDI model helpers such as midiInputPreflightToPlainTextReport() and midiOutputPreflightToPlainTextReport(). The editor may decide when to copy or display the string, but it should not own the diagnostic prose.

MIDI Health should expose two copy actions:

• COPY REPORT: the complete diagnostic report for support, bug reports, and deep troubleshooting.
• COPY STEPS: a compact MidiProjectHealthSummary::toPlainTextNextSteps() checklist for musicians who only need to know what to do next.

Both strings must come from the MIDI model layer. Do not rebuild the next-step prose in PluginEditor; future support bundles, guided setup assistants, and possible in-app help should all quote the same model-owned language.

The MIDI Sync workbench follows the same rule. midiSyncPreflightToPlainTextReport() should bundle runtime observation, sync policy, and outbound transport intent into one copyable receipt without sending clock, transport, SPP, Song Select, MTC, MMC, or any other hardware-affecting message.

The MIDI Timing workbench should use midiTimingPreflightToPlainTextReport() for its copyable report. UI-only loopback pulse settings may be passed into the helper as a label, but timing facts, latest measurement status, Hardware Passport timing labels, and warnings should remain model-owned.

The dashboard should also render the embedded MidiProtocolCoverageReport when explaining MIDI readiness. That report is intentionally conservative: it separates backend-ready families from UI-ready families and marks anything that can affect external hardware as requiring explicit confirmation.

Recommended layout:

• Header: one concise status line, such as 4 MIDI lanes | 2 controls | 1 hardware | 3 Automation rows | SpaceAge ready; hardware unverified.
• Lanes card: armed input lane, input channel, playback/export channel, route target, Hardware Passport, and warnings.
• Controller card: assignment count, unresolved mappings, duplicate/source warnings, and an Open Assignments action.
• Hardware card: Hardware Passport count, SysEx snapshot count, missing output devices, transport/clock warnings, and Open Hardware Passports.
• Expression card: expression event count and Automation row count, with a link to Automation now and future Piano Roll-grade automation rows later.

The dashboard is a status and navigation surface, not a sender. It must not send SysEx, bank/program, MIDI Clock, Start/Stop/Continue, Song Position Pointer, Song Select, MTC, MMC, or raw MIDI thru. Any send-capable action must remain behind its own explicit confirmation and log.

Hardware Recall Preview

Before SpaceAge sends bank changes, program changes, or SysEx snapshots to external hardware, the user should see a clear preview of the exact recall plan.

The backend source of truth should be HardwareRecallPlanSummary, built by CinematicDrumsAudioProcessor::buildHardwareRecallPlanSummary(). The UI should render summary rows instead of raw MIDI messages.

Each row should show:

• Label: Bank Select MSB, Bank Select LSB, Program Change, or SysEx: Patch Name.
• Message: plain MIDI description, such as CC 0 value 0 on CH 4 or SysEx, 7 bytes.
• Source: Hardware Passport id or SysEx snapshot id when useful for troubleshooting.
• Delay: any explicit send delay.
• Safety: whether confirmation is required.

The preview should also show Hardware Passport warnings such as missing output devices, invalid bank/program ranges, missing snapshots, or invalid SysEx bytes.

The preview is not consent. The first-pass MIDI Hardware panel now exposes explicit send actions for program recall and program recall plus attached SysEx, but both routes show the recall plan first and require confirmation before calling queueConfirmedHardwareRecall() and writing to the recall log.

Hardware Transport / Sync Preview

External sync should be previewed with the same caution as hardware recall. Before a Hardware Passport is allowed to send transport or clock, SpaceAge should explain the plan in rows.

The backend source of truth should be MidiTransportPlanSummary, built by CinematicDrumsAudioProcessor::buildHardwareTransportPlanSummary().

Hardware Passports are the edit surface for sync policy. The MIDI SYNC panel is a preflight/report surface: it should summarize observed runtime sync, saved Hardware Passport roles, and outbound transport intent, but it should not become the place where users secretly authorize hardware behavior. A selected Hardware Passport may expose a Sync Role Editor with:

• Clock role: Internal Tempo, Follow Host, Send MIDI Clock, or Receive MIDI Clock.
• Device capabilities: Clock, Song Position Pointer, MTC, and MMC.
• Transport roles: send SpaceAge transport on playback, or chase incoming hardware transport.
• One explicit save action that updates the Hardware Passport but never sends MIDI.

Saving a sync role that can affect hardware must use MidiHardwareSyncPolicyPreview. The confirmation report should state that the save action sends no MIDI immediately, then name any future playback sends such as MIDI Clock, Start, Continue, Stop, or Song Position Pointer, name incoming chase behavior such as MIDI Clock, SPP, MTC, or MMC, and list missing input/output/capability warnings before the Hardware Passport is updated.

This separation keeps the mental model stable: Hardware Passports describe what a piece of hardware can do and what SpaceAge is allowed to do with it; Sync preflight shows whether the whole studio conversation is ready.

Each row should show:

• Label: Song Position Pointer 16, Start, Continue, Stop, or MIDI Clock stream begins.
• Message: a plain MIDI description.
• Delay: any intentional delay before the message.
• Clock state: whether the row represents continuous MIDI Clock rather than a one-shot message.

Warnings should explain missing output devices, disabled clock permissions, mismatched clock modes, devices not marked as clock followers, or devices that cannot follow Song Position Pointer.

Like recall preview, transport preview is not permission to send. The first-pass MIDI Sync panel should show observed incoming sync/status counts, last SPP/MTC chase sample offsets, sample-aware position-chase evidence, and outbound hardware sync intent for clock/transport-enabled Hardware Passports, so the user can see both sides of the sync conversation before we expose deeper controls.

MIDI Learn

MIDI Learn should be the fastest path from "I touched a knob" to "that knob controls this."

First-pass direct-control learn now exists for many APVTS-backed controls. Right-clicking, or Ctrl+Alt-clicking, a learnable slider, supported dropdown, or supported toggle opens a tiny context menu that can arm MIDI Learn for that exact param: target. This is deliberately the same backend learn request used by MIDI Maps, so the mapping appears in the same assignment table, inherits the same 14-bit CC handling, pickup behavior, and can be cleaned up with the same row actions.

Direct-control learn now reaches APVTS-backed sliders plus many supported ComboBox and ToggleButton controls. If the visible target already has mappings, the direct-learn menu can replace mappings for that target. Before capture, it also asks the broader source-intent question in musician language: replace the same hardware source's older assignments, or add the new mapping as a macro. After capture, MIDI Maps shows a model-owned receipt explaining whether older source mappings were removed or the source now controls multiple targets.

MIDI Maps should make macro behavior visible without treating it as suspicious. When one enabled hardware source drives multiple targets, assignment rows should show MACRO SOURCE plus the target count. Exact source-target duplicates remain repair-worthy; one source feeding several different targets is a performance/control-surface idea and should be displayed as intentional unless the user chooses a replacement cleanup action.

Basic Flow

1. The user clicks Learn MIDI on a SpaceAge control.
2. The control enters a clear armed state: Learning: move a knob, slider, wheel, pedal, or pressure source.
3. SpaceAge captures the next valid CC, pitch bend, channel pressure, or poly aftertouch message.
4. The UI shows the learned source in plain language, such as CC74 on CH 3 or Pitch Bend on CH 1.
5. If the user chose replacement, SpaceAge keeps the newly learned mapping and removes older mappings that use the same hardware source. If the user chose macro, SpaceAge preserves the older mappings.
6. The Learn strip reports the capture receipt: learned source, destination target, removed older target count and labels, or macro target count and labels.
7. The user can adjust the range, invert the response, enable pickup, edit the curve, or delete the mapping later in MIDI Maps.
8. The mapping is saved with the project and appears in the Controller Assignment Browser.

Learnable Targets

Any APVTS-backed SpaceAge parameter should be learnable by default. The UI should group targets by musical area, for example:

• Global and transport-safe controls.
• Lane mixer controls.
• Redshift and native synth parameters.
• Drum pad and instrument controls.
• Effect parameters.
• Future VST wrapper parameters.

Non-parameter actions, such as lane mute, solo, arm, clip transpose, or transport actions, should use explicit action: or lane: target ids rather than pretending to be synth parameters.

Editing A Learned Mapping

After capture, the user should be able to set:

• Enabled or disabled.
• Input channel or Omni when supported by the source type.
• Min and max target values.
• Invert response.
• PICK soft takeover can be enabled per MIDI Map row. When enabled, SpaceAge ignores incoming controller movement until the mapped value reaches or crosses the current software value, preventing sudden parameter jumps when hardware and project state disagree.
• Optional label notes such as Keystep cutoff knob.

The default should be useful immediately: full source range to full target range, enabled, and project-persistent.

Learn Safety

MIDI Learn should ignore SysEx, MIDI Clock, Start, Continue, Stop, Song Position Pointer, Song Select, MTC, MMC, active sense, and other messages that are not useful continuous controls. Panic and reset messages should never become learned assignments.

High-resolution MIDI 1.0 controllers need explicit language. If the user learns a coarse/MSB controller such as CC1, the assignment row should mention its fine/LSB companion, for example 14-bit companion: CC33. If matching LSB traffic arrives, SpaceAge now merges the pair automatically. If the user learns the fine/LSB half directly, SpaceAge should warn that this is the fine half and recommend learning the MSB for normal control. MIDI Maps now has a first-pass live assignment meter, so the user can see that a learned control is moving. A later explicit pair-mode UI should show a more detailed high-resolution value meter rather than two confusing 7-bit rows.

If a source is already assigned, SpaceAge should warn before adding another assignment:

• This controller already controls Redshift Cutoff. Add another assignment?
• Choices: Add, Replace Existing, Cancel.

Duplicate repair is narrower than remapping. The current MIDI Maps REPAIR action removes only exact duplicate source-target rows, keeping the first learned row. It must not erase a deliberate macro where one hardware control drives multiple targets. MIDI Maps rows also expose KEEP when a source drives multiple targets: it keeps the chosen mapping and removes the other mappings from that source. Direct-control learn now has a target-focused replacement path for the visible control and a source-focused Replace Hardware Source / Add as Macro choice before capture, followed by a post-capture receipt.

The backend replacement primitive now exists and is wired into direct Learn: after a source is captured and the user chose replacement, the processor removes all other mappings that use that source while keeping the newly chosen mapping. That action no longer happens silently; the capture receipt tells the user whether they replaced older targets or created/preserved a macro assignment.

The pre-capture preview model now exists too. While a Learn request is armed, SpaceAge can inspect the moved hardware control before committing the assignment, report the exact source/target, and list any existing targets already attached to that source. The next UI step is to insert a friendly confirmation layer when that preview reports a conflict: Replace Source, Add Macro, or Cancel.

Controller Assignment Browser

The Controller Assignment Browser is the map of all learned and manually created control assignments in the project.

Purpose

The browser answers three user questions:

• What hardware controls are mapped?
• What do they control?
• Are any assignments conflicting or broken?

Recommended Layout

Each assignment row should show:

• Source: CC74 on CH 3, Channel Pressure on CH 1, Poly Aftertouch note C3 on CH 10.
• Target: Redshift Cutoff, Lane 2 Volume, Pad 08 Pitch, or future VST parameter name.
• Group: Synth, Mixer, Drum Composer, Lane, Effect, or Hardware.
• Range: user-facing min and max values.
• State: Enabled, Disabled, Missing Target, or Warning.
• Actions: Edit, Disable, Replace, Clear.

The browser should offer filters for:

• Source channel.
• Target group.
• Enabled or disabled mappings.
• Duplicate sources.
• Missing targets.
• Hardware Passport association, when known.

Manual Assignment

Manual assignment should be available for users who know exactly what they want:

1. Click Add Assignment.
2. Choose source type: CC, pitch bend, channel pressure, or poly aftertouch.
3. Choose channel and source number where applicable.
4. Choose target from the target browser.
5. Set response range.
6. Save.

Manual assignment should use the same validation and summaries as MIDI Learn.

Diagnostics

Warnings should be plain and actionable:

• Duplicate source: CC74 on CH 3 controls 3 targets.
• Missing target: this parameter is no longer available.
• Range is reversed. This is allowed and will invert the control.
• This mapping listens to Omni and may respond to multiple controllers.

Diagnostics belong at the browser level as well as on individual rows.

Hardware Passports And SysEx Vault

Hardware Passports describe external instruments and controllers. The SysEx Vault stores named device snapshots and setup dumps. Both are project data. Neither is permission to send data automatically.

The first-pass SysEx Vault lets the user choose a stored snapshot, rename it, write a plain-language note, set an exact send delay, and attach or detach it from a Hardware Passport. It also exposes one-dump live capture through ARM CAPTURE, CANCEL, SAVE CAPTURE, and COPY CAPTURE: an armed capture listens for one incoming SysEx dump, auto-disarms into a review receipt, and stores the result as confirmation-required. These edits and captures are bookkeeping/review actions only. Actual program recall or SysEx recall remains in the guarded Hardware Recall flow, where SpaceAge previews the message list, bytes, delays, output device, and warnings before queueing anything.

Hardware Passport Fields

A Hardware Passport should let the user save:

• Display name, manufacturer, and model.
• Input device and output device.
• Default MIDI channel.
• Optional bank MSB, bank LSB, and program number.
• Clock and transport capabilities.
• Whether the device is expected to follow external sync.
• Linked SysEx snapshots.
• Notes for setup, cabling, or patch recall.

The UI should clearly distinguish displayed program numbers from MIDI wire values. Many hardware manuals show programs as 1-128, while MIDI sends 0-127.

Creating A Hardware Passport

Recommended entry points:

• New Hardware Passport from the Hardware Passports panel.
• Create Hardware Passport From This Lane from a Lane MIDI Routing card.
• Create Hardware Passport From Import when a MIDI file contains program/bank/SysEx setup data.

When created from a lane, SpaceAge may copy the lane's channel, input device, output device, and route target. It should not invent bank/program/SysEx values.

SysEx Vault Fields

Each SysEx snapshot should show:

• Name.
• Linked Hardware Passport, if any.
• Manufacturer/model notes.
• Byte size.
• Short hex preview.
• Source: imported file, captured dump, pasted bytes, or manual import.
• Delay or pacing hint.
• Created/updated date.
• User notes.

The default Vault view should hide full raw bytes behind an Inspect Raw Data action. The main view should focus on identity, size, source, and safety.

Recall Preview

Before sending anything to hardware, SpaceAge should show a recall plan:

• Output device.
• MIDI channel.
• Bank MSB, Bank LSB, and Program Change messages, if present.
• Linked SysEx snapshots, with names and byte sizes.
• Pacing or delay between messages.
• Warnings from Hardware Passport validation.

The user must confirm the exact action:

• Send Recall To Hardware
• Cancel

If SysEx is included, the dialog should say so plainly: This will send SysEx data to your external device. This may change patches, memory, or device settings.

Recall Log

After a recall attempt, the UI should show a concise log:

• Queued or failed status.
• Message label.
• Output device.
• Byte count.
• Delay.
• Error text if unavailable.

This log should be about explicit recall attempts only. It should not mix in live lane playback traffic.

Send Queue Progress

The MIDI Hardware page should also show SpaceAge's current hardware-send queue state:

• Pending live lane hardware messages.
• Pending confirmed recall/librarian messages.
• Pending SysEx message count.
• Pending raw byte count.
• Pending planned recall delay.
• Dropped-message warnings.

This is a confidence signal, not a device receipt. It reports what is still pending inside SpaceAge's own queues. First-pass restore receipts can record no verification, manual verification, standard ACK/NAK/CANCEL/WAIT classification, or timeout, but model-aware librarian transfer status still belongs to a later deeper workflow.

MIDI Import Wizard

The import wizard should protect users from surprising MIDI data while helping them get musical material into SpaceAge quickly.

Step 1: Preflight Summary

When a MIDI file is opened or dragged in, SpaceAge should inspect it before changing the project.

The first page should summarize:

• Number of tracks.
• Timeline length.
• Used channels.
• Notes and likely lane roles.
• Tempo, meter, and key metadata, if present.
• Controller, pitch bend, pressure, program/bank, and SysEx data.
• Transport/sync data.
• Any warnings.

The summary should use human language:

• Channel 10 looks like drums.
• Channels 1 and 2 contain expressive melodic notes.
• This file contains device setup data.
• This file contains SysEx. SpaceAge can store it safely, but will not send it during import.

When channels can become SpaceAge lanes, the wizard should render backend MidiImportLaneCandidate rows. Each row should show the source channel, suggested lane type, suggested lane name, note/expression counts, and any review requirement. Examples: Ch 10 -> Long-form drum lane, Ch 02 -> Expressive instrument lane, or Ch 03 -> Hardware setup review.

Current behavior: safe melodic/instrument channel candidates and GM channel 10 drum candidates can be committed directly as new Arrangement lanes and clips from the preview panel. Drum rows import as long-form drum lanes so long MIDI files are not truncated to the classic 64-step Drum Composer grid. Same-channel notes and expression payloads are imported into new pattern payloads, and SysEx can be stored in the Vault.

The current preview also exposes channel include/exclude rows. Importable melodic/instrument and GM drum rows are checked by default; unchecking a row removes that source channel from the split commit. Melodic/instrument rows expose compact Instrument Slot and playback/export MIDI Channel controls. Drum rows show a disabled Long-form Drum Lane destination and keep playback/export on MIDI channel 10. Guarded rows remain visible with explanatory language but are not editable as lane-import choices yet. This is deliberately narrower than the final wizard: it gives users real control over safe note splits and basic destination routing today without pretending that hardware setup conversion or setup-data mapping are complete.

Step 2: Choose Import Shape

Default options should be practical:

• Import As One Clip
• Create Lanes From Channels
• Use Channel 10 As Drums
• Preserve Expression Data
• Review Program/Bank Changes
• Store SysEx In Vault
• Ignore Transport/Sync Messages

The wizard should make a best guess, then let the user override lane type, destination instrument, route target, and channel. The current pass lets the user include or exclude safe melodic/instrument and GM drum source channels, choose each melodic row's Instrument Slot plus playback/export MIDI Channel, and import channel 10 as a long-form drum lane. The commit schema also carries lane-name and input-channel options, so richer lane type, lane naming, input filtering, and Hardware Passport routing controls can be added without another backend rewrite.

Before the user commits, the wizard should render a dry-run MidiImportApplyPreview checklist. This final page should say exactly what SpaceAge will do: create lane rows, import one clip, preserve Automation rows, review tempo/meter/key metadata, review device setup, store SysEx in the vault, or ignore transport/sync messages. The preview is still not mutation; it is the last confidence-building step before the actual import.

The current selected-pattern import confirmation already uses MidiImportApplyPreview::toPlainTextReport() for its action-preview text. Preserve that model-owned source of truth as the UI grows from a text-heavy confirmation into a card-based wizard. The editor may choose layout, but the MIDI model owns the planned-action language.

When the user accepts the wizard, the UI should submit a MidiImportCommitRequest built from buildRecommendedMidiImportCommitRequest() or an edited equivalent. This request captures the chosen shape (Inspect only, Import as one clip, or Create lanes from channels), source channels, Channel 10 drum mapping, expression preservation, metadata review, device setup review, SysEx Vault storage, transport/sync ignore behavior, and confirmation state.

After the import applies, the UI should render a compact MidiImportApplyResult receipt. It should use the same vocabulary as the preview: clips imported, lanes created, performance expression preserved, patch/setup payload preserved, protected setup-only messages reviewed, SysEx snapshots stored, song metadata reviewed, transport/sync ignored, and warnings. This gives users a plain-language "what happened?" answer and creates a future hook for import history.

Step 3: Program, Bank, And Device Setup

If the file contains bank/program changes, RPN/NRPN setup data, protected channel-mode/reset messages, or SysEx, SpaceAge should ask what to do:

• Preserve Bank/Program and RPN/NRPN as setup payload where musically appropriate.
• Keep Local Control, Omni, Mono, Poly, All Notes Off, All Sound Off, and Reset Controllers as review-only unless the user later creates an explicit hardware setup action.
• Convert to Hardware Passport defaults.
• Store SysEx snapshots in the Vault.
• Ignore setup data.

Program/bank data must not silently change internal SpaceAge presets, SoundFont patches, or external hardware. Any conversion into a SoundFont preset, lane instrument state, or Hardware Passport default needs a visible user choice.

Current MIDI PATCH coverage for RPN/NRPN, Data Entry, and protected channel-mode/reset data is guarded, not casual. Complete standard RPN cards can queue after explicit confirmation, NRPN cards require a queue-safe Hardware Passport definition, and protected channel-mode/reset rows remain copy-only. Grouped RPN/NRPN editing, broader Hardware Passport dictionary matching, and deeper queue-receipt polish remain unfinished.

Step 4: Final Review

Before import, SpaceAge should show:

• Lanes that will be created or updated.
• Clip names and estimated lengths.
• Expression data that will be preserved.
• SysEx snapshots that will be stored.
• Data that will be ignored.

Primary actions:

• Import
• Back
• Cancel

Import should never send SysEx, start external transport, or open raw MIDI thru.

MIDI Export Preview

Before writing a MIDI file, SpaceAge shows a compact export preview built from backend MidiExportReadinessSummary data. This first-pass panel is wired for selected pattern, selected Arrangement clip, whole Arrangement, and drums-only Arrangement export. It summarizes the file plan and then opens the save dialog only after the user chooses to export.

Export Scopes

The preview supports:

• Selected pattern export.
• Selected Arrangement clip export.
• Whole Arrangement export.
• Drums-only Arrangement export.

Required Preview Rows

The preview shows:

• Export scope and target label.
• BPM and PPQ.
• Timeline start/end steps for clip or Arrangement exports.
• Lane count and clip count.
• Unique pattern count.
• Lane rows with lane name, playback/export MIDI channel, route target, and clip count.
• Drum note event count.
• Piano note event count.
• Chord Engine marker count.
• Expression event count.
• Warnings for empty exports, preserved gaps, or hardware-routed lanes without output devices.

The dialog renders buildPatternMidiExportReadiness(), buildArrangementClipMidiExportReadiness(), or buildArrangementMidiExportReadiness() and avoids duplicating lane/clip counting in editor code.

Before opening the file chooser or writing files, the dialog also calls spaceage::midi::buildMidiExportJobPlan(). The job plan converts the readiness packet into customer-facing rows: one single-file row, one lane/track row per exported lane, recommended .mid filenames, route/channel labels, included payload flags, and any diagnostic rows for empty exports. It also reports stemTrackCount, recommendedStemFolderName, and offersStemPackage so the UI can explain when a whole Arrangement is shaped cleanly enough for a multi-file MIDI stem package. Whole-Arrangement MIDI preview now exposes both choices deliberately: write the reviewed single MIDI file, or choose a parent folder and write a package containing the full Arrangement MIDI plus isolated lane MIDI files and a basic manifest.json.

MIDI Stem Package Import / Repair Preview

When a user opens a MIDI stem package folder or manifest.json, the UI should call spaceage::midi::inspectMidiStemPackage() before offering any import or repair action.

The preview should show:

• Package folder and manifest path.
• Project name, generated date, app version, full-arrangement MIDI file, and checksum algorithm.
• Ready-for-import state.
• File count, stem count, missing file count, size mismatch count, and checksum mismatch count.
• Per-file status: file name, type, lane number when present, size status, checksum status, and warnings.
• A "Copy Report" action using MidiStemPackageInspection::toPlainTextReport().

If readyForImport is false, the primary action should become repair/reveal/cancel rather than import. Do not auto-import on drag/drop; inspection is a trust-building review surface.

Tone

The preview should read like a collaborator checking the suitcase before travel: "3 lanes, 4 clips, channels 10/6/7, expression included, ready." It should not expose raw byte trivia unless the user asks for advanced diagnostics.

Lane MIDI Input And Output Routing

Each Arrangement Lane should have one compact MIDI Routing card. The card should be visible enough to build trust without crowding the main arranging workflow.

Required Fields

The lane card should show:

• ARM / MIDI IN: whether the lane is armed for live input and recording.
• INPUT CH: Omni or a fixed incoming MIDI channel.
• PLAY/EXPORT CH: the channel used for lane playback and MIDI export.
• Input device, when device selection is available.
• Source-identity status: saved input devices are visibility-checked, but live per-event physical-source enforcement requires the dedicated input-device manager. Until then, the armed lane and MIDI channel filter are the enforceable live controls.
• Output device, when hardware output is available.
• Route target: Internal Instrument, Hardware Only, Internal + Hardware, or Export Only.
• Hardware Passport assignment, if Hardware Passports exist.

The labels must not collapse into a generic MIDI field. Input filtering and playback/export channel are different user decisions.

Expected Behavior

If a lane is armed with INPUT CH Omni, it accepts normal learnable and recordable performance data from any incoming channel.

If a lane is armed with a fixed input channel, SpaceAge should ignore non-reset incoming MIDI on other channels for live input, recording, and performance-controller capture. Panic and reset messages should still pass safely.

PLAY/EXPORT CH controls generated lane MIDI during playback and MIDI export. It should not rewrite the original source channel silently except where lane-aware export intentionally uses the lane channel.

Selecting a Hardware Passport on a lane is an assignment of intent only. It must not send bank/program changes or SysEx. A separate recall action is required.

Route Targets

Route target labels should be plain:

• Internal Instrument: play the lane's SpaceAge instrument and normal plugin MIDI stream.
• Hardware Only: send generated lane MIDI to hardware and suppress internal sound.
• Internal + Hardware: play both the internal instrument and selected hardware output.
• Export Only: stay silent during live playback, but remain part of MIDI export.

If a hardware route is selected without an output device, the lane should show a warning and remain safe.

Expression Lanes

Expression lanes let users see and edit performance data that is not just notes.

Supported Lane Types

First product-ready Automation rows should include:

• CC lanes, including mod wheel, sustain, expression, pan, and volume.
• Pitch bend.
• Channel pressure.
• Poly aftertouch.
• Program/bank lanes for review and deliberate export/hardware workflows.

SysEx should not be an editable timeline lane. It belongs in the SysEx Vault with explicit recall behavior.

Transport and sync messages should not become Automation rows. They belong in the MIDI Sync / Hardware Passport sync-role workflow; final polish still needs MTC offsets, MMC record/locate options, and deeper diagnostics.

Editing Behavior

Expression lanes should live near the Piano Roll or clip editor for the selected pattern payload.

Current doorway rule: MIDI TASKS > Automation... should open the Automation editor directly. Settings may still contain the same doorway as a hub button, but a musician shaping a pattern should not have to remember the Settings path before finding automation/expression data.

Ownership rule: Automation edits the selected Shared PTN, Clip Local, or Lane Local payload. Playback and Arrangement export resolve all three through one effective model. Copy, paste, variant, save/load, and deletion must preserve the selected identity.

The user should be able to:

• Add points or events.
• Select, move, copy, paste, and delete events.
• Draw ramps for continuous data where appropriate.
• Quantize or thin dense controller data.
• Show the source channel.
• Change the output channel deliberately when lane export requires it.
• Temporarily hide or disable a lane without deleting data.

Recorded expression data should appear automatically after recording. Imported expression data should appear when preserved by the import wizard.

The editor should treat expression payload editing as processor-owned. Use getMidiExpressionLaneSummaries() to decide which lanes exist, then use addMidiExpressionEvent(), replaceMidiExpressionLane(), and removeMidiExpressionLane() for direct changes. Use the shared expression transform backend for quantize, scale, offset, and thinning operations. This keeps CC, pitch bend, pressure, program, and bank edits on the same safety path as recording, import, playback, and export.

Before the full drawable lane editor exists, expression rows should still show compact contour previews for editable lanes. These mini-shapes help the user recognize ramps, jumps, flat values, and dense controller gestures without opening a deeper editor. Setup rows such as Bank Select, Program Change, RPN/NRPN, and Data Entry remain review-only and should not show an editable contour.

Transform previews should show matched, changed, and removed event counts before committing anything destructive. Pitch bend must retain its MIDI 1.0 0-16383 range; CC, program, pressure, and bank lanes remain 0-127 unless a later MIDI 2.0 model extends the value vocabulary.

Display Rules

Use musical labels first:

• Mod Wheel (CC1)
• Sustain Pedal (CC64)
• Expression (CC11)
• Pan (CC10)
• Pitch Bend
• Channel Pressure

Raw CC numbers should remain visible for users who need exact controller detail.

For pitch bend, the UI should remind users that MIDI 1.0 pitch bend affects the whole channel. Slide-style workflows are safest on monophonic lanes unless future per-note expression support exists.

Safety Confirmations

Safety confirmations are not a sign of fear. They are how SpaceAge earns trust with external hardware.

Actions That Require Confirmation

SpaceAge should ask before:

• Sending SysEx.
• Sending bank/program recall to external hardware.
• Sending a combined hardware recall plan.
• Enabling raw MIDI thru.
• Enabling external clock or transport send.
• Applying an import choice that converts setup data into Hardware Passport defaults.
• Replacing an existing controller assignment when the source is already mapped.
• Deleting a Hardware Passport that is assigned to lanes.
• Deleting SysEx snapshots linked to a Hardware Passport.

Confirmation Dialog Requirements

Every hardware-affecting confirmation should show:

• The exact output device.
• The Hardware Passport name.
• The MIDI channel, if relevant.
• The messages or snapshot names involved.
• Whether SysEx is included.
• Any validation warnings.
• A clear cancel path.

Preferred button wording:

• Send Recall
• Send SysEx
• Enable MIDI Thru
• Apply Import Choices
• Cancel

Avoid vague buttons like OK for hardware actions.

After any hardware recall attempt, the hardware page should show a compact queue summary:

• Total recall messages attempted.
• How many queued and how many failed.
• SysEx message count and total bytes.
• Planned send-delay total.
• Latest output device/Hardware Passport touched.
• Plain-language warning if any message failed.

This summary is not a replacement for a full librarian send-progress view. It is the minimum user-facing proof that SpaceAge attempted the intended hardware action and did not silently autosend anything else.

When a restore response is available, the page should show the first-pass restore receipt separately from queue progress. A receipt may say unverified, manually verified, ACK, NAK, CANCEL, WAIT/timeout, or unrelated SysEx; it must not imply the device accepted a dump merely because SpaceAge queued bytes successfully.

The Hardware page should expose two copy actions beside the explicit recall buttons:

• COPY LOG copies the session hardware recall log report, including queued/failed counts, SysEx/program counts, bytes, planned delay, latest output, warnings, and detailed queued/failed message entries.
• COPY QUEUE copies the active hardware MIDI queue progress report, including pending live/recall/SysEx counts, bytes, planned delay, DIN wire estimate, completion estimate, and dropped-message warnings.

These are support/trust affordances, not send actions. They must never transmit MIDI or mutate project state.

MIDI Sync Policy

MIDI Sync UI should read from the backend MidiSyncPolicySummary instead of duplicating Hardware Passport interpretation in editor code. The summary should show:

• Hardware Passports that send MIDI Clock.
• Hardware Passports that send Start/Continue/Stop/SPP with playback.
• Hardware Passports configured to receive clock or chase incoming transport.
• Hardware Passports that need review before sync behavior is trustworthy.

This keeps the Sync panel, MIDI Health, support diagnostics, and a future guided Sync setup page aligned. It also makes the customer-facing rule simpler: SpaceAge should explain sync intent before it performs or follows sync behavior.

The focused Sync panel should also show per-passport role rows so a user can identify the exact device/Hardware Passport involved. Counts are useful for scanning, but rows are needed for trust: "which Hardware Passport is sending clock?" should be answerable without opening another panel.

The focused Sync panel should expose a COPY REPORT action backed by model-owned plain text. That report should bundle incoming sync runtime evidence, sync authority/policy, per-passport role readiness, and outbound transport intent. It is a diagnostic/preflight receipt only; copying it must never send Clock, Start/Continue/Stop, SPP, Song Select, MTC, MMC, SysEx, or alter project routing.

MIDI Stem Package Inspection

The Library page owns first contact with exported SpaceAge MIDI stem packages. CHECK / IMPORT MIDI PACKAGE should accept either a package folder or its manifest.json, call spaceage::midi::inspectMidiStemPackage(), and render the resulting MidiStemPackageInspection object directly.

Dragging a .mid file into SpaceAge may continue to open the existing MIDI import review path. Dragging a package folder or manifest.json should open the same read-only package checker instead of attempting a blind MIDI import.

The inspection surface is read-only until it has a clean package preview and an explicit confirmed import action. It should show:

• Ready-for-import state and summary.
• Manifest path and package folder.
• Package file, stem, missing-file, size-mismatch, checksum-mismatch, and warning counts.
• A compact file preview.
• A scrollable plain-text report.
• COPY REPORT, REVEAL PACKAGE, IMPORT STEMS when clean, and CLOSE.

Do not let package inspection, reveal, copy-report, repair-preview, unzip, overwrite, or relink anything by itself. The import/repair wizard may start from this same inspection object, but mutation needs its own explicit button, preview, confirmation, and receipt.

The future package import/repair wizard should render spaceage::midi::buildMidiStemPackageImportPreview() rather than raw manifest fields. The preview owns the customer-facing decision language:

• Ready to import.
• Repair missing package files.
• Review size mismatches.
• Review checksum mismatches.
• Review non-blocking package warnings.

Import buttons should remain disabled while the preview reports blocking issues. Repair buttons should explain exactly which file or lane needs attention and should create a receipt when the package state changes.

When the preview is clean, the future wizard should render spaceage::midi::buildMidiStemPackageImportPlan(). The plan should show the full Arrangement MIDI reference, each lane stem that would become an importable lane, the intended channel/route facts, musical event counts, support files, and warnings. Import buttons should create an explicit MidiStemPackageImportCommitRequest, then call CinematicDrumsAudioProcessor::applyMidiStemPackageImport(packageOrManifest, request, true) only after the user confirms. That processor helper is the approved mutation path: it re-inspects the package, rebuilds the plan, refuses broken packages, honors inspect-only/reference-only modes without creating lanes, imports clean lane stems through the existing MIDI import engine, and returns a MidiStemPackageImportApplyResult receipt for the UI to show immediately. A broken package should only produce inspect-only or repair actions.

The first visible surface is intentionally compact: CHECK / IMPORT MIDI PACKAGE remains read-only until it displays a clean plan, then enables IMPORT STEMS. Pressing that button asks for confirmation, imports through the processor boundary, and swaps the report text to the receipt. A confirmed package import should feel like one user action: one Undo should remove the imported package lanes/clips. Future polish can grow this into a multi-page import wizard, but the safety contract should remain the same.

Safe Defaults

SpaceAge should default to:

• Store SysEx, do not send it.
• Preserve expression data, do not flatten it.
• Ignore transport/sync messages on import unless the user opts in later.
• Assign Hardware Passports to lanes without recalling them.
• Show warnings before replacing mappings or deleting linked data.
• Send panic/reset conservatively and visibly when requested.

MIDI Device Template Draft Apply

MIDI Device Template apply must remain a preview-first flow until the user can see a full diff. The current backend supports a safe first mutation:

• Build a model-owned preview from the selected template.
• Build a model-owned before/after diff for the target lane.
• Show the guarded APPLY DRAFT button beside the selected Device Template, close to the diff it will apply.
• Require explicit confirmation before project mutation.
• Create a normal project checkpoint before mutation.
• Create one Hardware Passport draft and optionally attach it to the target lane.
• Set the lane's PLAY/EXPORT MIDI channel expectation from the template.
• Store a single processor-owned rollback snapshot before mutation.
• Send no MIDI: no test notes, Program Change, Bank Select, MIDI Clock, transport, or SysEx.
• Display a customer-facing apply receipt after mutation and let COPY RECEIPT copy preview, diff, and receipt together.
• Expose UNDO DRAFT only after a successful draft apply with an undoable receipt. It must confirm first, call the rollback helper, display the rollback receipt, and send no hardware MIDI.

Normal Undo and the rollback helper both restore the previous Hardware Passport list and the target lane's prior routing/channel/Hardware Passport state. If no target lane is available, the apply flow may still create a Hardware Passport draft; the receipt must make that unattached state clear so the user knows there is a follow-up routing step. The visible UI should keep saying "preview/draft" until hardware-send actions are separately designed, confirmed, logged, and tested.

Definition Of Done

The current MIDI 1.0 UI workflow is launch-closeout ready when:

• A user can learn a hardware knob to a SpaceAge parameter in one short flow.
• A user can browse, edit, disable, and remove mappings from one assignment browser.
• A user can create a Hardware Passport, link SysEx snapshots, preview a recall plan, and send it only after confirmation.
• A user can import a MIDI file after seeing what SpaceAge will preserve, convert, store, or ignore.
• A user can see each lane's MIDI input, input channel filter, playback/export channel, route target, and Hardware Passport at a glance.
• MIDI Health, MIDI Input, and MIDI Out can turn high-priority setup warnings into guided navigation buttons that open the correct repair surface without silently mutating project routing.
• MIDI Health can copy one complete model-owned plain-text report containing project readiness, protocol coverage, expression/patch setup, sync/timing, hardware counts, suggested repairs, and warnings.
• MIDI Sync can copy one focused model-owned plain-text report containing observed incoming sync/status evidence, last SPP/MTC chase sample offsets, sync authority, per-passport readiness, and outbound hardware transport intent.
• MIDI Protocol Coverage can produce a copyable plain-text current MIDI 1.0 closeout report that names blocker families and next actions, so support and internal QA are not forced to interpret the colored row display by memory.
• MIDI readiness objects should expose copyable plain-text reports from the model layer. Project readiness, MIDI Input, MIDI Out readiness, MIDI Out runtime, and device inventory should not rebuild their support prose inside editor code.
• SysEx Vault can copy model-owned snapshot/Vault and live-capture reports. Each SysExSnapshotSummary and capture/restore receipt should own its own text, and the Vault should use model helpers rather than rebuilding snapshot facts in PluginEditor.
• A user can edit common expression data without losing channel intent.
• Dangerous MIDI actions are explicit, logged, and reversible where project data is involved.
• External-hardware marketing claims are held until real-device validation exists for the relevant workflow, not merely because SpaceAge can queue the right bytes.
• SysEx restore success requires device-response evidence such as ACK/NAK/WAIT/CANCEL, or a manual verification receipt after checking the hardware.
• True MPE remains future work; current closeout can preserve and report MPE-like MIDI 1.0 expression without claiming full MPE support.

Arrangement Automation Doorway

The Arrangement Canvas should expose MIDI performance automation through two plain routes:

• Click the visible Automation doorway from the Piano Roll, Arrangement controls, MIDI TASKS, or Settings when a real clip/pattern or lane context exists.
• Open the lane Signal / MIDI command menu and choose Automation (CC / Bend / Pressure)....

Both routes open the same owner-scoped Automation editor. Empty lanes should not imply that clip-local automation can exist without a clip context. Shared PTN uses the linked-edit guard; eligible Arrangement context also exposes Clip Local and Lane Local owners.

The end result should feel like a workstation that respects external gear, not a DAW that accidentally blasts MIDI bytes into the room.

Arrangement Record Button Doorway

The Arrangement page should get its own transport Record button so melodic and harmonic parts can be performed directly into the song. The button should call the same lane-owned recording backend already used by the armed-lane flow; it should not create a second hidden recording model.

The target rule is simple: the selected/armed Arrangement lane owns recording. If the playhead is inside a real clip on that lane, record into that clip at the clip-local step. If the playhead is in empty lane space, create a new lane-owned clip at the playhead and record there. If no lane can receive input, the button should guide the user to select or arm a lane rather than falling back to a loose pattern.

The Arrangement button should reuse existing count-in, metronome, overdub/replace, snap, quantize, source-policy, input-channel filter, record-latency compensation, and Automation preservation behavior. The Piano Roll remains the detailed editor after the fact; Arrangement becomes the place where a user can play against the whole song.

Detailed implementation plan: see docs/Arrangement_Record_Button_Plan.md.

2026-07-13 - Automation Keyboard Delete Rule

Keyboard Delete/Backspace in Automation is a precision edit command: it deletes selected automation points or switch edges. Whole-row deletion is intentionally reserved for the visible DELETE ROW button so a user cannot accidentally remove an entire controller row by pressing Delete with only the row selected.

2026-07-13 - Automation Copy/Paste Scope Rule

Automation copy/paste remains row-local and owner-scoped. Copy is read-only. Paste writes into the currently selected owner. Only Shared PTN paste requires the linked-pattern guard; Clip Local and Lane Local paste stay with those owners.

2026-07-13 - Shared-PTN Wording Rule

Customer-facing Automation copy should prefer shared PTN data, shared PTN rows, or shared PTN automation over older pattern-owned phrasing. The older phrase is technically accurate, but shared PTN matches the visible PTN labels and makes the linked-clip consequence easier to understand. Use VARIANT as the user-facing escape hatch when only one linked clip should diverge.

2026-07-13 - Shared-PTN Risk-Copy Rule

Automation risk copy should name the ownership object directly. Use shared PTN for current selected-pattern automation in paste receipts, delete warnings, shared-edit acknowledgement, report scopes, and final-editor QA rows. Avoid older pattern-owned, PTN-owned, or shared-pattern wording in current UI surfaces because it fragments the user's mental model.

2026-07-13 - Armed Lane Truth Rule

When MIDI recording or live monitoring is active, the armed Arrangement lane is the live controller destination. Selected clips, selected notes, selected patterns, and visible Piano Roll content are editing focus only. Compact record summaries should show the armed lane, input filter, output MIDI channel, and edit focus so the user can predict exactly where incoming MIDI will go.

2026-07-13 - MIDI Input Live Owner Rule

The MIDI Input page/report must surface the live input owner near the top of the diagnostic stack. If an Arrangement lane is armed, that lane owns incoming MIDI; selected clips and visible editors are edit focus only. If no lane is armed, the UI should say so plainly before listing channel, device, or filter details.

This prevents the user from guessing whether MIDI is going to the selected clip, visible Piano Roll, last touched lane, or current page. Live input is an explicit armed-lane contract.

2026-07-13 - Multi-Controller Input Rule

SpaceAge may open every visible physical MIDI input so controllers remain available without reconnect rituals. The user-facing rule is: the armed Arrangement lane owns incoming MIDI, then its optional input-device pin and channel filter decide what is accepted.

If multiple physical inputs are open and the lane is not pinned to a device, the UI should describe this as valid but cautionary: useful for deliberate layered controllers, risky for deterministic recording. The next action should be to pin the desired controller, use distinct MIDI channels, or consciously leave the lane open.

2026-07-13 - Record Take Receipt Rule

When MIDI recording captures data, SpaceAge should leave a visible receipt. Piano Roll mode may select and refresh the recorded note, while Arrangement view should repaint and report the capture in the status line. The receipt should identify the armed lane and pattern; melodic captures should additionally show note name, local start, length, velocity, and MIDI channel. This is not decoration: it is proof that live input landed in the intended musical container.

2026-07-13 - Arrangement REC Button State Rule

The Arrangement REC button should always expose its current doorway state:

• ARM LANE means no valid Arrangement lane target exists yet.
• REC means a selected or armed lane can receive recording.
• COUNT means count-in is active and pre-count-in notes should not be captured.
• REC IN means incoming MIDI is actively landing in the lane-owned Arrangement recording path.

The lane badge remains the deeper truth surface, but the transport button should never collapse this state back to vague REC / STOP REC wording while Arrangement recording is the active workflow.

2026-07-13 - Recording Receipt Rule

When MIDI recording captures an editable expression event instead of a note, the status line should identify it as Automation, name the event kind, and show useful facts such as controller number, MIDI channel, start position, and value. This prevents recorded automation from feeling invisible or mysterious.

2026-07-13: Piano Roll Automation Context Rule

When a user enters Piano Roll from an Arrangement clip, the compact Automation strip must show the effective shared PTN expression data for that clip context. When no clip context exists, it falls back to the selected pattern. Clicking the strip remains the fast path into the full MIDI expression editor. Do not describe lane-local or clip-local automation as present until those ownership models are deliberately implemented, routed, exported, and documented.

2026-07-17 - Automation Entry Point Labels

Arrangement automation entry points use one stable compact label: AUTO. The editor/report layer, not the button label, explains whether the current target is Shared PTN, Clip Local, or Lane Local. This keeps MIDI automation visible without introducing another inspector layer or forcing the user to decode ownership before opening the tool.

Automation Doorway Language

• AUTO is the Arrangement and Piano Roll doorway into editable performance automation.
• The UI must say whether edits affect Shared PTN, Clip Local, or Lane Local data before the user changes anything.
• Shared PTN edits still need the linked-pattern guard: edits affect every clip using that PTN until the user makes a VARIANT.

MIDI Health QA receipt workflow (implemented 2026-07-15)

1. Open Settings > MIDI Health.
2. Follow FIX NEXT to perform the current closeout test.
3. Choose SAVE QA.
4. Select PASS, FAIL, or BLOCKED; enter evidence notes, checker, and receipt/log references. BLOCKED also requires a reason.
5. Save. SpaceAge appends the cold record to project.midi.qaReceipts; this action sends no MIDI and touches no hardware.
6. Repeat for the next unsatisfied category. When every active category has evidence, the button becomes REVIEW QA.
7. REVIEW QA displays the full evidence ledger and offers a clipboard copy for support or release review.

QA closeout result rule (implemented 2026-07-15)

• Saved evidence alone is not completion. The latest valid saved result for a category must be PASS.
• A later FAIL or BLOCKED reopens the category and keeps SAVE QA available for a retest.
• Receipt authority follows append order. Earlier results remain reviewable and are never overwritten.
• One PASS applies to the current category-level closeout contract, not to unrelated categories.
• MIDI Health and MIDI Protocol must always display the same receipt-adjusted coverage state.

Hardware Passport SysEx policy rule (implemented 2026-07-15)

• The customer-facing Passport must distinguish manual verification from automatic SDS correlation.
• Automatic correlation requires an explicit midi-sds dialect, valid device ID, and opt-in switch. Missing policy is not an error; it is a visible manual-review state.
• Never label an undeclared Yamaha, Roland, or other vendor checksum as valid or invalid from manufacturer identity alone. Show not evaluated until a verified message-family policy exists.
• A response may alter a restore only when source input, device ID, packet number, dialect, and active-attempt identity all agree.
• Unknown or ambiguous replies remain available for inspection but must not create a success receipt.

Lane Local timeline view

When Automation targets Lane Local, the graph is an Arrangement-timeline editor rather than a repeating pattern editor. The playhead and new points use the absolute Arrangement step. FIT TIMELINE frames the current song/section extent and must not draw a source-loop overlay. Shared PTN and Clip Local continue to use source-relative views.

Effective summaries may show all audible layers, but the write owner remains exactly what the owner selector names. A Lane Local edit must never be translated through a clip source start or repeated once per clip.

2026-07-17 Automation Piano Roll Doorway Rule

The Piano Roll AUTO button and MIDI TASKS > Automation first resolve the selected Arrangement clip or selected destination lane, then open Automation for that Arrangement context. If no Arrangement context exists, they fall back to the shared-pattern Settings doorway. This keeps automation reachable from the musical work area while preserving a safe fallback for loose pattern editing.

2026-07-17 16:33 - Automation Badge Label Rule

Arrangement lane automation badges use the stable label AUTO even before rows exist. Row counts and tooltips may explain whether the click creates the first row or opens existing rows, but the visible doorway should not split into AUTO+, AUTO, and AUTO N as if those were different tools.

MIDI Timing Trust Boundary

• The MIDI Timing page must not imply that recorded-event calibration removes real-time performance latency. Customer-facing copy should keep two concepts separate: live feel is the audio/MIDI driver path; recorded alignment is post-capture placement compensation stored per Hardware Passport.
• USB and 5-pin DIN paths can require different timing evidence even when they share the same MIDI interface. Treat each route as its own Passport calibration candidate.

MIDI Health Hardware Proof Visibility

• The Health panel should show hardware proof as a two-part cockpit: HW PROOF says how many proof items remain, and HW NEXT says the next action the user should take. This keeps external-device validation practical without hiding the workflow in copied reports.

2026-07-24 09:23 - Lane Badge Automation Tooltip Rule

Arrangement lane Automation badge tooltips must not describe Automation as only Shared PTN data. They should explain that the editor displays the effective layered view and that the write owner can be Shared PTN, Clip Local, or Lane Local. Shared PTN keeps the linked-clip/VARIANT warning; Clip Local and Lane Local stay scoped to their owner.

2026-07-25 - Arrangement REC Targeting

Arrangement REC is lane-armed and playhead-first. The selected clip may remain the editing context, but it must not steal live recording unless it is also the real clip under the playhead in the armed lane. If the playhead is over a real clip in the armed lane, record into that clip/pattern. If not, create a lane-owned clip at the intended insertion point. The target summary should plainly say the armed lane, playhead clip or new clip, input channel, MIDI channel, and that selection does not steal live input.

2026-07-25 - Armed Lane Status Detail

When a lane is armed for MIDI input, the status line should keep the full route summary: lane name, instrument/mixer identity, input filter, and MIDI output channel. Command panels and routing panels must not overwrite that summary with a generic armed/disarmed message. The moment of arming is the user's confirmation that incoming performance data will go where they expect.

Opening an Arrangement clip is also an arming/navigation action. Its status should add the clip-editing context while preserving the armed route details, because the user is about to play or record into the newly opened musical context.

2026-07-25 - Recorded Note Receipt Detail

After a melodic MIDI note is captured into an armed Arrangement lane, the status receipt should be traceable without opening another panel. Include the pattern, armed lane name, lane instrument/mixer identity, input filter, note name, start, length, velocity, and recorded MIDI channel. This keeps live recording feedback consistent with the armed-lane route model and helps diagnose wrong-lane or wrong-channel confusion immediately.

2026-07-25 - MIDI Route Summary Contract

Every customer-facing status line that changes or reports live MIDI routing should use the same route facts rather than hand-written partial strings. The required facts are: armed lane name, lane-owned instrument/mixer route, MIDI output channel, input channel filter, and selected hardware input device when present.

This applies to arming a lane, changing the input filter, changing the selected hardware input device, changing playback/export MIDI channel, reporting the recording target, and confirming captured notes or expression data. The goal is simple: a user should always be able to answer "what am I playing, where is it going, and what input is allowed?" without reverse-engineering the UI.

Hardware-oriented route changes follow the same rule. Changing route target, hardware output device, Hardware Passport, or creating a Hardware Passport should report target mode, output device, Passport ID, input device, input filter, mixer channel, and MIDI channel in one consistent sentence. A musician connecting a MiniNova, QY-70/QY-100, or other external instrument should not have to remember which field they changed last to know what the lane will send.

Hardware test notes are hot actions and must be even more explicit. Queued or failed test-note receipts should repeat the same route facts, then clearly separate what SpaceAge knows from what the user must verify: the app can prove that it queued the note to a target route, but the musician must listen to the external device to confirm audible response, patch/channel correctness, and physical-cable reality.