namir-clap: parameter changes made in the plugin GUI are never reported to the host

[ErwanLegrand]

crates/namir-clap/src/params_ext.rs:155, 178, src/audio.rs:189, src/ui_host.rs:183

ClapUiHost::set_param writes the mirror and the engine ring only. Both flush impls take _output_parameter_changes: &mut OutputEvents and ignore it, process() never touches events.output, no ParamGestureBegin/ParamGestureEnd is emitted anywhere, and HostParams::request_flush() is called by nothing in src/ (only the test host implements it).

A user turning a knob in the embedded editor therefore cannot have the move recorded as automation, and the host's generic parameter UI stays stale until it independently re-polls get_value. Not booked as a known gap in the FRS, architecture or roadmap.

Fix: queue GUI-originated changes and drain them into output_parameter_changes in both flush impls and into events.output in process(), wrapped in gesture events; call request_flush() from the main thread when inactive.

[ErwanLegrand]

Partial. The reported defect — a knob moved in the embedded editor never reaching the host — is fixed. Leaving open for one residual path.

Landed (63afed5): ParamMirror gained a gui_pending bitmask set only by set_by_key_from_gui (crates/namir-clap/src/param_mirror.rs:131-139), which is the setter ClapUiHost::set_param now uses (ui_host.rs:239) while host-originated writes keep the unmarked one, so the plugin does not echo the host's own automation back. emit_gui_param_changes (params_ext.rs:213) drains that set wrapped in ParamGestureBegin/ParamGestureEnd, and is called from all three outbound points: process() into events.output (audio.rs:445-449), and both flush impls into output_parameter_changes (params_ext.rs:347, :373). HostParams::request_flush is now called from the main thread when work is pending (main_thread.rs:92-103). A failed push restores the bits (restore_gui_pending) and an unmatched gesture is tracked so the End goes out on the next call.

Remaining: a preset recalled from the plugin's own editor still has no wake-up. spawn_recall_preset stores params_rescan_pending on a worker-pool thread (worker_jobs.rs:220-224); the only two HostSharedHandle::request_callback() sites in the crate are audio.rs:286 and audio.rs:403, both audio-thread latency/priority paths. request_param_flush_if_pending returns early unless has_gui_pending() or an open gesture (main_thread.rs:98), and the recall path sets neither — ParamMirror::load is a plain store (param_mirror.rs:172-177). So rescan_params_if_pending (main_thread.rs:81) is serviced only opportunistically, from on_main_thread (:134) or a host-initiated PluginMainThreadParams::flush (params_ext.rs:332), and nothing guarantees either arrives. Until one does, the host's cached parameter values stay stale after a GUI-driven recall.

The one-line fix is not available: request_callback() needs a HostSharedHandle<'a>, and SharedInner deliberately holds none (shared.rs:697-700) because ThreadPool::spawn requires 'static. clack 0.1.1 exposes no 'static form, and erasing the lifetime would need a fourth #[allow(unsafe_code)] file — a D-5.3 decision, not a patch.

---

Generated by Claude Code