added math signals

CLAUDE.md

@@ -727,6 +727,99 @@ far the largest file.
   pins the same way (`pin_pause_window()` sets `pinned_` from the frozen range), so the frozen
   picture is equally immovable; resuming or leaving trigger mode clears it.
 
+- **The session is the layout.** `LayoutState` persists what makes a reopened scope look like the
+  one that was closed: the window, the rows and their slot signals, the calibration, **the enabled
+  signals**, **the math channels with their graphs** and **the measurements pane**. Signal identity
+  is the *name* throughout (a CONFIG renumbers channels), 'enabled' is read off the channels the
+  model built -- an enabled signal is exactly one that produced a channel -- and `apply_layout()`
+  installs the graphs **before** assigning the rows, since a row may hold a math channel's name and
+  that name is only a signal once its graph is in. Two format rules, both learned the hard way:
+  write an op or a measure *type* as its index through `math_op_at()`/`measure_type_at()`, never as
+  the raw enum value -- those accessors' orders are the dialog's, not the declaration order, so
+  writing one and reading the other silently renames operations. And a top-level key written after
+  a `[[table]]` belongs to *that table* in TOML: `enabled = [...]` emitted after `[[calibration]]`
+  was parsed into the last calibration record and the enable state was lost without a word.
+  `mkdirs()` used to create only components with a trailing slash, so `~/.config/udpscope` was never
+  made and the *first* save failed silently -- worth knowing when a layout change "does not stick".
+
+- **A math channel *is* a channel.** `ScopeModel::set_math_channels()` appends one *synthetic*
+  `SignalInfo` (with `math = true`) per math channel after the stream's own, so the panel's switch,
+  the plot binding, the measurements and the export all handle a derived channel without knowing it
+  is derived -- and another math channel is a valid `Source` for exactly the same reason. The
+  *samples* come from the producer: `Acquisition::on_data()` collects each channel's value for the
+  slot and calls `ScopeModel::push_math_sample()` **once per stored slot**, before the deferred
+  latch (`publish_event()` clamps its snapshot to every ring's `produced()`, so a derived sample
+  pushed later would be missing from the capture's newest slot). The math therefore runs on the
+  *stored* (filtered, decimated) samples, which is also why `math_prepare()` gets `slot_dt() *
+  time_stride`: a cutoff the user typed in Hz means the rate the filter will actually run at.
+  `src/math_channel.cpp` is the engine: a graph evaluated as a **list walked in order**, so a node
+  may only read ones *before* it and a cycle is impossible by construction rather than by a check
+  (`math_channel_valid()` states that as a message the dialog shows). `/tmp/check_math.cpp`-style
+  checks verified the biquads against known responses (LP fc=100 Hz: 50 Hz -> 0.97, 2 kHz -> 0.002;
+  BP fc=1 kHz q=2: 200 Hz -> 0.05, 1 kHz -> 0.95, 4 kHz -> 0.05) -- **keep test sines below
+  Nyquist**: at `dt = 1/10000` a "5 kHz" test tone is the Nyquist point itself and says nothing.
+  The editor is the *compact graph*: nodes as boxes on a `GtkDrawingArea`, click to select (its
+  parameters in the form beside it), click an output port then an input port to wire, drag to move;
+  no pan/zoom. Its widgets are created once and only shown, hidden and set by `math_dialog_sync()`,
+  so no rebuild can invalidate a live callback handle -- the same shape the measurements dialog
+  uses. `UDPSCOPE_PROBE_MATH_MS` defines two graphs and opens the editor (a construction crash test
+  as much as a state check), and the dump prints each derived channel's extremes beside the
+  source's. Four rules here were wrong first and are worth keeping:
+  * **A `Source` may only name an *acquired* channel** -- `ScopeModel::channels()`, which is what the
+    dialog's dropdown lists, **and both places that create a node must take one from there**.
+    `signals().front()` is the stream's *timestamp* signal: it is first in every CONFIG, it is not
+    acquired, and a graph sourced from it validates and then reads NaN for ever. The dialog's
+    default was fixed first and the pane's `+` was not, which is what "[ch] -> [gain x2] produces
+    only nan" was. The dropdown also *reconciles*: a node whose source is not in the list is moved
+    to what the form is showing, rather than the form showing one channel while the node holds
+    another, and `Apply` refuses a source that is not acquired (the engine's validator is about the
+    graph -- an output, every input wired above it -- and cannot see the acquired list).
+  * **The ingest must skip a derived channel.** `Acquisition::on_data()` iterates every channel and
+    reads each one from the packet, so a math channel with no signal read *zero* and pushed it --
+    while `push_math_sample()` pushed the real value on the same slot. Two pushes per slot into a
+    ring whose time ring advances once: the values alternated between the real one and 0, and once
+    both rings wrapped the value ring had drifted a whole window off the time ring, so the derived
+    trace disappeared. `ChannelInfo::math` is the flag (`channel.math`) and the loop `continue`s on
+    it. **A derived channel's `values(c).produced()` must equal `live().time().produced()`** -- one
+    push per stored slot -- and the dump prints both as `N samples vs M time slots` for exactly
+    this: the arithmetic on the plot can look plausible long after the pairing is wrong.
+  * **`gtk_window_destroy()` does not emit `close-request`.** The math dialog's pointer is cleared
+    by a `close-request` handler, so a Cancel that *destroyed* the window left `app.math_dialog`
+    pointing at a dead widget: every later `open_math_dialog()` took the "already open" branch and
+    presented it -- a GTK critical, and nothing on screen, which is "I cannot edit a math channel
+    again". Both paths close (`gtk_window_close()`), which emits the signal, lets the handler clear
+    the pointer, and then destroys. The same lesson as the other GTK traps here: a programmatic
+    destroy is not a user close, and only one of them runs the handlers.
+  * **Boxes must not overlap on the canvas.** The first auto-place staggered nodes by 24 px for a
+    132 px box, so every box sat on the one before it, `math_node_at()`'s topmost-first search always
+    returned the last, and a drag or a click landed on the wrong node -- which reads as the dialog
+    ignoring the pointer. Two columns spaced 160 px apart, rows 58. The probe prints the box the
+    drag *began over* for exactly this reason. Offering the whole signal list let a graph name something nobody is
+    acquiring (no data for ever) and put the stream's timestamp signal, which has no samples, in it.
+  * **`prepare_math_locked()` runs from `rebuild_locked()`, so *every* plan change re-prepares the
+    filters**: a CONFIG, an enable/disable, and a window change that moves the decimation (that path
+    is `set_target_span()` -> `rebuild_locked()`). Coefficients are a function of the *stored*
+    interval and the filter's state is the old rate's history, so both are rebuilt together.
+    Preparing only on an edit left the cutoff wrong and the state ringing after any window change --
+    that is what "I tested a low pass and it was a mess" was.
+  * **The graph's output defaults to the *last* node, and a node added to a linear graph becomes
+    it.** The output began at index 0 -- the *source* -- so every operation a user built was
+    computed and then thrown away: a gain of 2 and a low pass both produced a channel equal to its
+    input. The output is drawn as the orange dot and settable explicitly, so an earlier node chosen
+    deliberately is kept; this is the default for a graph that has never been given a choice.
+  * **`gtk_spin_button_new_with_range()` can leave the value at the range's *minimum*.** The offset
+    field began at -1e6, and `on_math_param_changed()` reads the widgets, so `x*2` saved as
+    `x*2 - 2000000`. Every numeric field is seeded with its own identity value; the range-minimum
+    default is never a useful starting point for a gain or a corner frequency.
+  * **The form's rows are grouped per *op*, not per field**: gain and offset are one group because
+    `gain + offset` is one op. The offset was a row of its own that nothing ever hid, which read as
+    a property of every node.
+  * **A `GtkSpinButton` holds zero decimals by default**, so every numeric field sets its digits
+    (4 for gain/offset/clamp, 3 for `fc`/`Q`); without that a 12.5 Hz cutoff was stored as 12 and a
+    gain of 0.25 as 0. And the canvas drag reports the *total* offset from where the gesture began,
+    so adding each update's delta to a value the handler then writes back is a runaway box -- it
+    must record the position at `drag-begin` and ignore a drag that did not begin on a box.
+
 - **Every instrument this app *computed* is out of the pointer's reach.** The trigger marker and
   the measurement marks are cursors created with `Plot::add_cursor()`/`add_h_ruler()`, and a cursor
   is grabbable by default -- so each takes `set_cursor_selectable(id, false)`. **Parking it outside
@@ -874,5 +967,17 @@ far the largest file.
   would clamp a legitimately short capture up to the requested window.
 - **The header bar's buttons are icon-only**, so headless probes must reach them
   through the `App` pointers (`trigger_toggle`, `pause_button`, …), not via
-  `find_labelled_button()`. The Arm/Disarm button in the trigger panel still has text.
+  `find_labelled_button()`. The **pane switches are toolbar buttons** too (`cursors_toggle`,
+  `measures_toggle`, `math_toggle` -- packed with `header_bar_pack_end()`, where the **first** packed
+  is the rightmost, and the bar is an *ancestor* rather than the parent because packing parents into
+  an internal box), and the cursors pane owns its own
+  **Reset** button rather than the overflow menu owning one for it. The dump prints
+  `panel controls: … ; toolbar, left to right: …` to say where they are and in what order. The widget
+  tree's child order *is* the visual order left to right, so that line reads as the *reverse* of the
+  pack order -- it is how an arrangement gets checked with no screenshot, and it is what finally
+  settled the pack-order rule above (two comments in `build_toolbar()` disagreed with each other and
+  one of them with reality): it is computed on the first *tick*, because the dump
+  runs after the window is destroyed and asking GTK about a widget then is four criticals, which is
+  how the first version of that line earned them. What stays in the menu is what acts on the *data*
+  (Fit, Export) and the two editors that are not panes (Layout, Signal list). The Arm/Disarm button in the trigger panel still has text.
 - Every source file carries an SPDX MIT header; match it in new files.