Adds an interactive notebook that provides real-time effect parameter control and visualization for the guitar pedal effects.
The notebook uses CFFI to call the C audio effects directly. Audio files
are processed sample-by-sample at 48kHz with the same int32/float32
precision as the hardware implementation.
Features:
- Per-file watching of C sources (convert.c, *.h) with automatic rebuild
- Direct C function calls via CFFI shared library (libeffects.so)
- Reactive UI updates parameter controls based on selected effect
- Waveform and spectrogram visualization with statistics
- Audio I/O via soundfile library
Setup:
- uv run marimo edit effects.py # creates isolated venv, autobuilds, and launches
or
- pip install -e .
- make libeffects.so # previous step should have done this, but just in case
- marimo edit effects.py
also hosted here, just for kicks: https://molab.marimo.io/notebooks/nb_XrY8GPWcHPJV9rPtmbdJvo/app disclaimer, I work on marimo professionally- but mainly like tinkering with things
Activity
5
qasim786789mo agoThe interactive dashboard is a really interesting idea, and the ability to tweak effect parameters in real time while visualizing waveforms and spectra is genuinely useful. The CFFI bridge to the C effects and keeping the same precision as the hardware path is especially nice.
That said, this PR introduces a fairly large, self-contained tool along with new workflow and packaging assumptions (uv, marimo, notebook-style UI). Before we can consider merging something like this, I think we need to clarify a few things:
• Whether an interactive notebook/dashboard fits the core scope of this project, or if it’s better maintained as an external companion tool. • If it is meant to live here, we should try to minimize new tooling and keep dependencies and setup as simple and conventional as possible. • It would help to separate any core changes from the dashboard itself so the review surface is smaller and easier to reason about.
Overall, the work is impressive and clearly useful, but I’d prefer to discuss direction and possibly narrow or restructure this before moving forward. Let me know what you think.
dmadisetti9mo agoThese are great organizational and scope concerns.
I agree that depending on a whole web-server is a bit heavy handed. On the flip side, in terms of UI - the web standard is incredibly flexible and addresses your styling concerns. For a small proof of concept, I can compile this project for web assembly (which marimo supports) and pushed to github pages with a sample style. Adding a github action would enable interactive documentation
Some thoughts on making this less of a monolith:
- generate
ffi.hon the fly. Removes maintenance burden of manually exporting a effect - break out the different visualization components into scoped, separate files
The tree would look something like
- pyproject.toml # uv is the only "installed" software needed. I run uv without python even
- dashboard/
- main.py # marimo app, imports from viz, builds
- compile.py # breakout the dynamic compilation I put in the notebook, now generate
ffi.h - viz/
- spectrogram.py
- ...
Self contained, but highly coupled to this project. I'm not sure if it makes sense for a dashboard and a TUI, but marimo could work with maturin. However, the complexity balloons to rust, python and c + emcc if doing webassembly exports.
edit: woops, hit send a little early
nice job
have you checked.?