Device becomes unresponsive after apply/export until USB replug

[oveddan]

Symptom

After running apply (and possibly export/list), the Twister stops responding to MIDI and has to be physically unplugged and replugged before it works again.

Likely cause

Every CLI command calls discover() first (src/cli.ts:123-125), which briefly opens and closes an output port (and input ports) on the Twister to send an identity-request SysEx. Immediately afterward, the CLI opens fresh input/output ports again for the real work (connectForApply at src/cli.ts:152, or connect at src/cli.ts:173). For apply specifically, this means the USB-MIDI connection to the device is opened and closed twice in quick succession, and connection.close() (src/cli.ts:168) fires immediately after the final full-snapshot read-back in applyPatchPlan (src/applier.ts:76-80), with no drain delay.

Class-compliant USB-MIDI controllers like the Twister run their MIDI stack on a small MCU with a shallow buffer. Tearing down and reopening the CoreMIDI connection back-to-back — especially right after a burst of SysEx traffic (writes plus a full config read-back, which can be dozens of messages) — is a plausible way to leave the device's USB-MIDI endpoint wedged.

Proposed fix

1. Add a short drain delay (~150-250ms) after the last MIDI traffic and before connection.close(), both in applyPatchPlan and after exportConfiguration in src/cli.ts.
2. If that alone doesn't resolve it, look at avoiding the redundant discover-then-reconnect cycle when the device index/identity is already known, to cut down on how many times the port is opened/closed per invocation.

To verify a fix

Run apply against a real connected Twister and confirm it keeps responding to MIDI (e.g. a subsequent export succeeds) without needing a physical unplug/replug.