The browser becomes
optional.
SHEET 00 / 06 — LEIBNITZ 4.0 ENGINEERING NOTE
Leibnitz 3.x proved that signal processing could run inside a browser tab. Leibnitz 4.0 stops trying to fit a research lab inside JavaScript, and instead becomes a scientific computation platform reached through an API — with the website serving as its documentation, onboarding, and showcase.
The browser was the right prototype. It isn't the right platform.
A signal-processing environment that lives entirely in a browser tab hits the same walls no matter how well it's built. None of these are bugs — they're the shape of the container itself.
JavaScript isn't built for heavy numerical workloads. Large transforms and iterative solvers slow down exactly when precision matters most.
CUDA, MKL, OpenCV, ITK, GSL, FFTW, and TensorRT have no clean path into a browser sandbox. Every one of them has to be reinvented or left behind.
File size and browser memory ceilings cap how much signal a person can even load, let alone process.
GPUs and specialized instruments stay out of reach when everything runs behind a tab.
Long-running or distributed jobs don't survive a closed laptop lid or a refreshed page.
Everything is an API call.
Every algorithm — FFT, Hilbert transform, PCA, wavelets, PDE solvers, MRI reconstruction — becomes its own service, reached the same way regardless of what runs underneath it.
Six categories, one calling convention.
Whether the request is a single-shot transform or a standing session, it's addressed the same way. A quick look at how the surface is organized:
Core Signal Processing
- FFT / IFFT / DCT
- Hilbert transform
- Convolution & correlation
- Resampling
Spectral
- Spectrogram · STFT · Welch
- Lomb periodogram
- Wavelets
- Synchrosqueezing
Image
- Filtering & denoising
- Segmentation
- Registration
- Morphology & feature extraction
Machine Learning
- Classification & regression
- Autoencoders
- CNNs & transformers
- LLM interface
Biomedical
- EEG · ECG · EMG
- MRI reconstruction
- CT
- Ultrasound
Mathematical
- PDE & ODE solvers
- Optimization
- Monte Carlo methods
- Sparse recovery
Change one sample. Don't recompute everything.
Most numerical APIs treat every request as a clean slate: new signal in, full recomputation out. Leibnitz 4.0's engine instead keeps a live computation graph and cached intermediate results, so a small change to the input only touches the part of the graph downstream of it.
The idea is grounded in a real result from filter design research: Li Lee and Alan Oppenheim's study of Parks–McClellan filters (MIT, 1997) found that individual filter coefficients settle toward a steady value as filter length grows. Coefficients from a shorter, already-computed filter turn out to be close approximations of the corresponding coefficients in a longer one — which means a filtering operation can be built up in stages instead of redesigned from scratch each time the length changes.
Leibnitz generalizes that observation past filter design: cache what's already converged, patch only what changed, and reuse the rest of the graph.
A patch, end to end
Written for the language you already use.
The API surface is designed so most people never write a raw HTTP call. A signal goes in, and a result — spec = leibnitz.fft(signal) in Python, the equivalent call in MATLAB — comes back. Full installers and reference docs land alongside the engine; for now, here's what's planned.
Access model
Anonymous demo access, API keys, OAuth, and institutional or team workspaces are all planned, so a solo researcher and a shared lab can both use the same engine without stepping on each other's jobs.
From software to operating system.
Leibnitz 4.0 is meant to grow from software for signal processing into a scientific computation operating system — algorithms as composable services, processing graphs that can be saved and shared, native libraries integrated once and reused everywhere, reached through a stable API instead of a browser-specific interface.
That's the shape this documentation exists to describe before a line of the engine ships: desktop clients, notebook integrations, command-line tools, lab instruments, and cloud clusters, all speaking to the same computational core.