[chengj7]

Removed environment.yml and deploy.yml used for binder hosting. Added pyproject.yoml and ci.yml for github pages hosting. Added matchedfiltering.py (Marimo notebook using plotly) and _matchedfiltering_mpl.py (Marimo notebook using matplotlib). Configured pyproject.toml and ci.yml to host _matchedfiltering_mpl.py.

[moble]

Looks great. Here are some things to fix.

• Installing packages takes forever; are there any that could be removed?
• Move content/_matchedfiltering_mpl.py to content/matchedfiltering.py
• Don't talk about plot controls
• Remove jupyter, jupyterlite, and binder links / mentions everywhere.
• CI triggers on the main and marimo branches
• pyproject.toml has some irrelevant stuff
• Adding a notch filter resets the ones already entered.
• "Recalculate" text needs polish
• widgets is called in utilities.py without being imported
• probably just remove section 8
• filter_cheat doesn't work currently; you won't need globals() because marimo does this sort of thing more naturally

[moble]

Here's what Claude has to say about the memory error:

---

Memory leak in the browser version: equalizer sliders crash the kernel

In the WASM (browser) version, dragging a few of the equalizer sliders down to −200 makes the kernel run out of memory:

MemoryError: Unable to allocate 512. KiB for an array with shape (65537,) and data type float64

After that, the notebook stops responding until the page is reloaded.

Cause

Every slider movement reruns the equalizer cell, and each rerun makes a new Matplotlib figure. These figures are expensive. Each holds
several 131,072-point traces, and marimo renders it at twice its DPI, which for a 19.5-by-10-inch figure is about 3900 by 2000 pixels.
While a slider is being dragged, it sends a stream of intermediate values, so a single drag can produce many figures.

plot_td_and_fd_mpl calls plt.close('all'), but that only removes pyplot's own reference. A figure, its canvas, and its axes refer to
one another, so the closed figures stay in memory until Python's cyclic garbage collector runs. That collector runs according to how many
objects have been allocated, not how much memory they use. These figures are few but huge, so up to ten of them were alive at once. In
the browser, the WebAssembly heap never shrinks once it has grown, and 32-bit WebAssembly caps it at 4 GiB.

Measurements

I dragged sliders to −200 in headless Chrome and recorded the WebAssembly heap and the number of live figures after each drag:

Point in the test	Heap as is	Heap with gc.collect()
After running all cells	557 MiB	464 MiB
Drag 1 (slider 8)	2,108 MiB, 10 figures	901 MiB, 1 figure
Drag 2 (slider 11)	2,761 MiB, 7 figures	1,058 MiB, 1 figure

Suggested fixes

1. Collect garbage right after closing the old figures in plot_td_and_fd_mpl. This is the fix measured above:

   import gc
   ...
   plt.close('all')
   gc.collect()  # Closed figures sit in reference cycles; free their large buffers now
   fig, (ax1, ax2) = plt.subplots(1, 2)

2. Debounce the equalizer sliders, so that marimo sends the value only when the slider is released. A drag then causes one redraw
   instead of dozens, which should also make the sliders feel more responsive, since each redraw takes a second or so in the browser. I
   haven't measured this one.

   mo.ui.slider(
       start=-200.0, stop=200.0, step=0.5, value=0.0,
       orientation="vertical", show_value=True, debounce=True,
       label=str(int(_freq)),
   )

I tested the gc.collect() fix on my scratch copy of the notebook, in which the helpers are folded into the notebook and the data loads from
public/.