feat: let apps write back their own params and notify the host

[kosmar]

Params travel host→device: the configurator sets them, the app reads them. An
app that lets the user pick a value on the hardware (a gesture that cycles a
genre or a voice, say) has no way to close the loop — the value is neither
persisted nor reflected, so the configurator keeps showing the old one until
the app task restarts.

Adds ParamStore::update(), which mutates, saves, and pushes the new values to
the host.

The push needs its own channel. APP_PARAM_CHANNEL carries request/response
replies, and an unsolicited push queued there gets drained as a stale reply to
a later GetAppParams — the host would see the wrong layout's state. So
APP_PARAM_PUSH_CHANNEL is separate, and the config loop selects on it while
idle. The select is cancel-safe: read_msg awaits on the frame channel, so no
partial frame is lost when the select flips.

#[allow(dead_code)] because the first callers are the WIP app branches
(#633, #604), which cannot compile against main without this.

Note for review: cargo clippy -D warnings currently fails on main itself
with a chunks_exact lint in tasks/midi.rs, unrelated to this change.

Test checklist (hardware)

• Configurator open, change a param on the device (Bassment genre gesture):
  the configurator updates live without a reconnect
• The changed value survives a power cycle
• GetAppParams for another layout still returns that layout's own state
  (no stale reply crossover)

Made with Cursor

[ArthurGibert]

Hi @kosmar ,

This is a significant UX change that I am not sure we'll go forward with.

Here is the reasoning. Parameters are meant to be set and forget settings and are meant to be fixed and never change unless the user changes it with the configurator. Anything that is that is dynamic has to be accessible with the channel UI and have LED feedback.

This goes with the UX intent that we have with Faderpunk which is to have a two stage workflow. First, one would create their layout and set the params. Second, the user would use the setup they created to perform and play the Faderpunk. The goal if this UX is to replicate the workflow of a modular synth were one select modules and put them into a case with limited space and play with it.

The goal of this are:

• Dissociate the performance aspect from the setup aspect and make Faderpunk feel like a instrument despite its morphability.
• Make the user stick with the apps for a longer period of time to make the user learn the function and sub functions of the device.

I want to avoid the dependence to the configurator for any apps.

Now, these are not points that are blocking this PR but I'd like to consider this longer.

However I don't think the implementation of this PR should be a blocker for all the apps that are currently stacked on top of it. I would suggest that the apps stacked on this PR are modified so that these can be reviewed independently.

[kosmar]

i think its mainly #642, that wants this. but more a convenience than necessity.
the idea is nice, i probably would not need a Pull button on presetpunk anymore, but its no roadblock for me, if we dont get it.

[kosmar]

only UX issue might be:
eg #642 allows to change settings via device interaction that are also config fields,
im not sure if other apps do that for smth like base notes or voltage ranges.
which means the config doesnt show the reality when the device is reconnected.
both behaviours are a tradeoff in some way.

[kosmar]

Split the non-blocking part into #647: ParamStore::update that mutates + saves to FRAM only (no host push). That unblocks the WIP apps that already call params.update without waiting on the configurator live-sync UX discussion here. When you are ready for the AppState push, it can land on top of #647 as a drop-in.

[ArthurGibert]

Superseded by #691, which takes a different approach: the device never pushes an unsolicited message (that broke the open configurator — see the review on this PR), and it adds the SDK mirror needed for installed apps to actually use this, which this PR never had. Thanks for opening the discussion that led to it.