DEV Community: Davinci Leonhard

We Tried to Find a "Future Signal" in Bearing Failure Data. It Was Just Structured Degradation.

Davinci Leonhard — Thu, 09 Jul 2026 10:08:32 +0000

TL;DR: Pre-failure noise in degrading mechanical bearings is famously predictive of time-to-failure. We asked a stricter question: is that structure directionally tied to the true future failure event, in a way present-state structure alone couldn't explain? We ran five falsification tests against six public bearing-degradation datasets to check. Every test failed to support directionality. What looked like a "signal from the future" was just the present being highly structured. This is independent research, not peer-reviewed — treat it accordingly.

The question

Rotating machinery gives off a lot of warning before it dies. Spectral entropy shifts, resonance patterns change, noise gets structured in ways that correlate strongly with time-to-failure. That correlation is well documented in the predictive-maintenance literature and isn't controversial.

What is a stricter question: is that structure oriented — does it point specifically at the true, upcoming failure event, in a way that couldn't be explained by the present state alone?

If the answer were yes, it would imply something stronger than "structured degradation." It would imply the current noise is carrying information specific to a boundary condition that hasn't happened yet. We named this the Dead Future Hypothesis, mostly as a label for the null we wanted to knock down — formally:

Pre-failure mechanical noise acts as a carrier for information flowing from the future terminal failure boundary. The adhesion cascade exhibits unique alignment with the true terminal state — alignment that should degrade under time-reversal, false terminal assignment, or cross-terminal label swaps.

If that's true, five specific things should happen. If any of them don't, the directionality claim collapses back into "the present is just really well structured" — no future-facing signal required.

The setup

We used six public bearing-degradation datasets:

PASS runs (clean, ordered degradation cascade confirmed): NASA IMS Run 3, PRONOSTIA Bearing 1_1, PRONOSTIA Bearing 3_2
FAIL runs (transient collapse only, no ordered cascade): NASA IMS Run 2, PRONOSTIA Bearing 1_2, PRONOSTIA Bearing 2_2

Earlier passes (v0.3–v0.5) had already established that PASS runs contain a reproducible adhesion cascade: a low-frequency band (the "Vanguard Band") lights up first, then the cascade climbs through broader frequency bands as failure approaches. That structure is real — it survives null-boundary controls and drift-matched virtual controls. The open question was whether it's directional.

Every test below scores structure using AUC (area under the ROC curve) from a simple decoder trained to separate a target window from the safe/early-life zone. 0.5 = indistinguishable from random, 1.0 = perfect separation. High AUC just means "this window is statistically distinguishable from normal" — it says nothing on its own about why. That's exactly the ambiguity the five tests below are designed to resolve.

The verification — five falsification tests

Each test predicts a specific, falsifiable signature that a truly directional signal must show. We ran all five (v0.6, the "Directional Adhesion Stress Test").

Test 1 — Time Reversal

Reverse the temporal order of each run, recompute every adhesion metric. A directional signal should collapse under reversal — AUC should fall toward the ~0.50 null baseline.

Forward AUC (avg):   0.940
Reversed AUC (avg):  0.940
Δ(t):                0.000

The reversed-time cascade was statistically indistinguishable from the forward one. In two of three PASS runs, the reversed score was marginally higher than forward — within noise, but the opposite of what directionality predicts.

Test 2 — False Terminal Assignment

Assign artificial "terminal" boundaries at 30% and 50% of bearing life, using the same drift-matched null controls as the true terminal. A directional signal should score the true terminal far above these fakes.

True Terminal AUC:        0.940
False Terminal AUC (max): 0.923
Specificity percentile:   ~50th

Fake failure points scored essentially as well as the real one. The cascade aligns with any structurally compatible boundary — it doesn't discriminate the true future event from an arbitrary mid-life one.

Test 3 — Cross-Terminal Specificity

Swap terminal labels across runs — apply NASA IMS Run 3's failure boundary to PRONOSTIA 1_1's data, and vice versa. A signal tied to one specific physical failure event should collapse badly under the wrong label.

True Label AUC (avg):    0.910
Swapped Label AUC (avg): 0.873
Cross-Terminal Δ:        0.037

A 0.037 drop is noise-level. The cascade is a general property of bearing degradation in PASS runs, not something wired to any individual physical failure event.

Test 4 — Vanguard Band Stability

Stress-test the Vanguard Band under random seeds, resampled windows, ±5% boundary shifts, and alternative null controls, to check whether it's a real physical structure or an artifact.

Forward stability:  0.96
Reversed stability: 0.94
Seed variance:       ±0.02
FAIL-run stability:  0.31

The Vanguard Band is real — it's stable and clearly separates PASS from FAIL runs. But it's equally stable under time reversal (0.94 vs 0.96), which confirms it's a genuine physical structure while simultaneously confirming it has no temporal orientation. This is the one test we call PARTIAL rather than a clean fail: the structure itself checks out, it just isn't directional.

Test 5 — Cascade Order Robustness

Represent the ordered band-activation sequence as a vector, compare forward / reversed / false-terminal / cross-terminal conditions against the canonical forward cascade using cosine similarity. Only the real forward condition should score high; everything else should be scrambled.

Forward / Reversed / False-terminal / Cross-terminal:  0.85–0.92
Null-shuffled baseline:                                 ~0.51

All four "real" conditions cluster together. Only literally random shuffling produces a different signature. The cascade order is an intrinsic property of how the degradation unfolds — not a fingerprint of a specific future event.

The result

Criterion	Required for directionality	Result
Forward > Reversed	Yes	Δ = 0.000 — FAILED
True terminal > False terminals	Yes	~50th percentile — FAILED
True labels > Swapped labels	Yes	Δ = 0.037 (noise) — FAILED
Vanguard Band stable only in PASS, not under reversal	Yes	Stable in both — PARTIAL
FAIL runs show no ordered cascade	Yes	Confirmed, but doesn't establish directionality — FAILED

Across the directional criteria, every test failed to support temporal orientation. The Dead Future Hypothesis is empirically rejected.

What this actually means

The interesting part isn't "retrocausality is fake" — nobody serious expected otherwise. The interesting part is that the thing we did find is still real: bearings exhibit a highly ordered, reproducible, statistically significant structural cascade before they fail. It's just undirected — a non-stationary spectral critical transition, not a message from the terminal event.

In other words: the present state of a degrading system is already so deeply structured that it deterministically constrains its own likely futures. That looks like prediction. It even looks a little like the future reaching back. But the arrow isn't there — you can run the tape backward and the structure holds just as well. The predictability was fully present in the current moment all along.

Caveats

This is independent research, not peer-reviewed. The datasets (NASA IMS, PRONOSTIA/FEMTO) are public bearing-degradation benchmarks commonly used in predictive-maintenance literature — full credit to those projects. Treat the falsification result as a solid negative result on a fun hypothesis, not a physics paper.

Methodology / reproducibility

The core scoring approach is a standard AUC-based decoder (separating a target window from the early-life safe zone) run per frequency band, cross-checked against drift-matched virtual null boundaries so the score can't be explained by generic drift alone. Each of the five tests above just changes what gets fed into that same scorer — reversed time order, a relabeled terminal, a swapped terminal, a perturbed band definition, or a shuffled order vector.

Code cleanup for public release is still pending — the current implementation is entangled with unrelated internal tooling. Full report and figures: Pinching Index — DIMProductions Research Archive

LinkinDAW: Connecting FL Studio to Browser-Based Web Audio Apps with WebRTC

Davinci Leonhard — Mon, 06 Jul 2026 12:38:38 +0000

LinkinDAW: Connecting FL Studio to Browser-Based Web Audio Apps with WebRTC

I’ve been building LinkinDAW, an experimental Windows VST3 connector that links FL Studio with browser-based Web Audio apps through WebRTC.

The idea is simple:

A DAW should be able to talk to a web app like an instrument.

In the current public alpha demo, FL Studio loads LinkinDAW as a VST3 plug-in. From there, LinkinDAW opens a browser launcher, starts a WebRTC room, and connects to Axion, a browser-based Web Audio instrument.

Once connected, FL Studio can drive the web app with transport, tempo, and note messages.

Demo Flow

The current demo shows:

Loading LinkinDAW inside FL Studio
Opening the web app launcher
Choosing Axion
Connecting the browser app through WebRTC
Pressing play in FL Studio
Hearing Axion respond in sync

This is still experimental, but the core concept is already visible: FL Studio can become the host, and the browser can become the instrument surface.

Why Browser Audio?

Web Audio has a different kind of creative energy.

It is fast to prototype, easy to share, visual by default, and open to unusual interfaces. But DAWs are still where many producers arrange, mix, and finish music.

LinkinDAW is an attempt to connect those worlds.

Instead of rebuilding everything as a native plug-in, the browser can stay the creative environment, while the DAW handles timing, transport, and production workflow.

Current Status

LinkinDAW is currently a public alpha.

What exists now:

Windows VST3 source code
FL Studio-focused workflow
WebRTC signaling prototype
Axion staging demo
Browser-based Web Audio integration
Experimental audio and export paths

What does not exist yet:

Installer
Signed binary release
General DAW support
Production-ready packaging
Finalized API for arbitrary Web Audio apps

So this is not a finished product announcement.

It is a working development milestone.

Axion as the First Target

The first serious demo target is Axion, a browser-based Web Audio app.

Axion is useful for testing because it has a real musical surface: drums, native 808 behavior, parameter controls, and browser-side export experiments.

The current direction is not to force every detail through MIDI piano-roll behavior. For example, 808 slides are better preserved inside Axion’s own playback/export logic than by pretending standard VST MIDI can represent every FL Studio slide behavior exactly.

That distinction matters.

The goal is not to fake a web app into becoming a traditional plug-in.

The goal is to make the DAW and the browser cooperate.

Repository

The source code is now public here:

https://github.com/DIMProductions/LinkinDAW

The project is experimental, Windows/FL Studio-focused, and currently source-first. There is no installer or binary release yet.

What I’m Looking For

I’m interested in feedback from people who care about:

Web Audio
DAW plug-in development
FL Studio workflows
WebRTC
experimental music tools
browser-native instruments

This is early, rough, and still changing.

But the door is open now.

If you are into DAWs, Web Audio, plug-ins, or strange music tools, come build this with me.

I Built a Piano Trainer That Measures Stability, Not Just Speed

Davinci Leonhard — Sun, 29 Mar 2026 23:23:17 +0000

Most piano practice tools measure speed.

Some measure note accuracy.
Some turn practice into a game.
Some help beginners learn what key to press next.

But there is a problem hidden underneath all of that:

speed is not the same as control.

A pianist can play fast and still sound unstable.
A trill can be quick but uneven.
A repeated-note passage can look impressive on paper, while the actual timing is wobbling underneath.

And that wobble matters.

Especially in repeated notes, trills, and high-pressure fast passages, the real issue is often not whether you can move your fingers fast enough.

It is whether you can stay stable while moving fast.

That question led me to build Piano Virtuoso 18.

Piano Virtuoso 18 is a browser-based piano trainer focused on something that most tools do not treat as the main event:

timing stability.

Instead of rewarding raw speed alone, it evaluates whether the player can maintain control, consistency, and evenness during short high-speed bursts.

You can try it here:

The problem: fast is visible, instability is not

Traditional practice makes it easy to notice obvious mistakes.

You can hear missed notes.
You can hear when the rhythm collapses completely.
You can tell when you simply cannot keep up.

But many technical weaknesses live in a more subtle zone.

A player may think:

“I can do this trill.”
“I can repeat this note fast enough.”
“My right hand is getting faster.”

But when you actually examine the timing at a finer level, a different picture can appear:

one note is consistently late
alternation becomes uneven under pressure
bursts accelerate and then decay
intervals drift away from the intended spacing
speed rises, but control falls apart

This is the zone I wanted to expose.

Because in real playing, especially in advanced piano technique, fast and unstable is not mastery.

Fast and stable is technique.

Why repeated notes and trills matter so much

Repeated notes and trills are not just “small exercises.”

They reveal the truth about control.

If your motion is unstable, these patterns expose it immediately.
If your timing is uneven, they punish it immediately.
If your hands can generate speed but cannot regulate it, they make that weakness obvious.

That makes them perfect for measurement.

So instead of building a general piano-learning platform, I focused on a narrower and sharper question:

Can timing stability be measured directly during short, fast piano actions?

That became the design center of Piano Virtuoso 18.

The idea behind Piano Virtuoso 18

Piano Virtuoso 18 is not designed as a generic tapping game.

It is not mainly about “how many presses can you do.”
It is not mainly about “did you hit the correct note.”
And it is not trying to behave like a full AI piano teacher.

Its core idea is much more specific:

measure the quality of high-speed timing behavior, not just the quantity of taps.

That means the system cares about things like:

micro-timing deviation
interval consistency
stability score
burst-control behavior
alternation evenness

The goal is to convert invisible technique problems into visible data.

What the trainer actually does

Piano Virtuoso 18 runs in the browser and works with MIDI input.

Its current design centers on short, measurable performance windows — especially 10-second sprints — because they create a clean situation for observing speed under pressure.

The current core modes are:

Erlkönig Mode

A repeated-note stability challenge centered on C4.

This mode is built for the kind of rapid single-note repetition that appears in advanced piano technique, especially where the issue is not merely speed, but maintaining uniform control.

Trill Mode

An alternation stability challenge using C4 ↔ D4.

This mode evaluates how evenly the player alternates between two notes, and how stable the timing remains during the burst.

These are simple exercises on the surface.

But that simplicity is exactly what makes them useful as a technical lens.

When the task is stripped down, instability has nowhere to hide.

The central metric: stability over time

The most important idea in the project is this:

raw speed is not enough as a score.

A player who produces more taps is not necessarily demonstrating better technique.
They may simply be generating more chaotic motion.

So Piano Virtuoso 18 treats stability as a first-class signal.

That means the score is influenced not only by how fast the notes arrive, but by how evenly they are spaced and how well the performer sustains timing quality across the entire attempt.

This is the real difference between a speed toy and a technique analyzer.

Visualizing the problem

Here is the kind of timing structure the system is built around.

This image represents an idealized view of alternation over time.

The horizontal axis is time.
The vertical structure separates note events in a repeating pattern.
In trill-style alternation, the important question is not only whether the player hits both notes, but whether those events remain evenly spaced and structurally consistent over the full burst.

That is where the interesting information lives.

Not in “did the note happen?”
But in:

when it happened
how evenly it happened
how much the spacing drifted
whether the player stayed under control

Once you look at performance this way, many familiar practice tools start to feel incomplete.

Why I built it in the browser

I wanted the system to be immediate, lightweight, and accessible.

That is why Piano Virtuoso 18 runs directly in the browser rather than requiring a heavy native installation.

For this kind of prototype and training system, the browser offers several advantages:

instant access
simple distribution
easy iteration
direct MIDI integration
no-friction testing across devices

That makes it easier to experiment with measurement ideas quickly.

And more importantly, it keeps the focus on the analysis itself, instead of burying the project under installation friction.

Why this is not just another rhythm game

At a glance, some people might think:
“Isn’t this just a tapping challenge for pianists?”

No.

That interpretation misses the point.

A tapping game usually rewards output volume:
more presses, more points, end of story.

Piano Virtuoso 18 is built around a different assumption:

bad speed should not be rewarded the same way as controlled speed.

That changes the meaning of the entire system.

If a player produces a lot of presses but their interval spacing is collapsing, that is not the same as true control.
If a trill becomes rhythmically unbalanced, that is not a clean success.
If the player’s burst profile shows instability, the score should reflect that.

So the trainer is not merely counting events.

It is judging whether the events remain structurally stable enough to represent real technique.

That is why I describe it less as a game and more as a stability-focused performance analyzer.

What makes this useful for real pianists

Most musicians already know the feeling of “I thought I played that better than I actually did.”

That gap between perception and measurable execution is where useful training tools can matter.

Piano Virtuoso 18 helps by exposing things that are usually buried inside vague intuition:

whether your repeated notes are actually even
whether your trill alternation is structurally balanced
whether your speed is sustainable or collapsing
whether your timing control survives pressure

This matters because once a weakness becomes measurable, practice changes.

You stop relying only on mood, self-estimation, or wishful thinking.
You can train against an observed problem instead of a vague feeling.

That is where real feedback begins.

Why I think “stability” deserves more attention

In many practice environments, speed gets the spotlight because it is easy to understand and easy to market.

It is simple to ask:
“How fast are you?”

It is much more interesting to ask:
“How stable are you at speed?”

That second question gets closer to what technique actually is.

Not motion alone.
Not effort alone.
Not excitement alone.

But regulated motion under pressure.

That is the territory Piano Virtuoso 18 is trying to formalize.

The broader idea behind the project

The deeper idea here is larger than one piano trainer.

I think there is room for a whole class of music tools that do not just teach content, but measure structural quality.

Not just:

what note was played
whether the answer was correct
whether the user finished the task

But:

whether timing stayed stable
whether motion stayed consistent
whether performance quality degraded under load
whether control survived intensity

That kind of measurement is interesting not only for piano, but for musical technique more broadly.

Piano Virtuoso 18 is one concrete attempt to move in that direction.

Current project links

If you want to look at the project directly:

Final thought

Most people can understand speed.

But in serious playing, speed is the easy part to admire and the dangerous part to overestimate.

The harder question is whether the performance stays stable when speed arrives.

That is the question that led me to build Piano Virtuoso 18.

Not a trainer that simply asks:

“How fast can you go?”

But a trainer that asks:

“How stable are you when you get there?”

Hunting the "Death Signal": From Occult Hypothesis to Non-Equilibrium Engineering

Davinci Leonhard — Tue, 10 Mar 2026 03:48:22 +0000

What happens when you try to audit the structural collapse of a system using nothing but pure math?

1. The Occult Origin Story

This project didn't start in a boardroom. It started with a haunting biological hypothesis: "Do organisms or complex systems emit a specific physical signal at the exact moment of their structural collapse—the moment of death?".

I wanted to find the "scream" of a system as it moves irreversibly from an ordered state to chaos. While this sounds like sci-fi, translating it into engineering terms revealed a universal challenge: detecting short-lived non-equilibrium transitions buried in massive environmental noise.

2. The Concept: Structural Collapse

To catch these "ghosts," we need to understand the physics of a regime break.

Energy Landscape: Most systems sit in a stable basin. A collapse occurs when a perturbation pushes the system across a barrier into a new, often destructive, regime.
Transition Signatures: This shift isn't just an anomaly; it has a structure. We look for Precursors (subtle instabilities) and the Winner Event (the primary transition).

3. The Architecture: Dual-Branch Auditing

A single filter isn't enough to isolate a regime break. My pipeline separates analysis into two distinct branches.

Environment Map (LF Branch): Tracks slow behavior, baseline drift, and environmental interference. This branch ensures we don't mislabel a simple drift as a structural event.
Transition Scan (HF Branch): This is the hunter. It isolates rapid changes and audits them using physical metrics like Irreversibility (the "arrow of time") and Persistence.

4. The Muddy Reality: 3 Deadly DSP Traps

Theory is easy; reality is brutal. In my early prototypes, my own tools were assassinating the signal. Here is how I solved it in v15 of the auditor.

Trap 1: The Self-Destruction of CMR

I initially used Common Mode Rejection (CMR) to kill noise.

The Failure: My "Death Signal" was a collapse hitting all channels at once.
The Logic: Subtracting the average across channels meant subtracting the target from itself.
The Fix: Disabled CMR by default to preserve common-mode anomalies.

Trap 2: The IIR Filter Rampage

I fed drifting signals straight into sharp Notch filters for 50Hz hum.

The Failure: Sharp IIR filters "ring" violently when they hit massive drifts.
The Result: The filter creates fake transients that look exactly like structural collapses.
The Fix: Order matters. Apply a Bandpass filter first to flatten the drift, then run the Notch stack.

Trap 3: The DC Offset Illusion

SNR calculations were failing even with clear pulses.

The Failure: 500ms windows often have a local DC offset that dominates power calculations.
The Logic: The energy of this offset hides the AC power of the actual signal.
The Fix: Implemented local mean-centering before RMS calculation to isolate the true signal.

5. The Solution: non-equilibrium-auditor

The final result is a transparent, explainable toolkit. No black boxes. Just audited physics.

Python Engine: death_audit_v15.py processes multi-channel data, ranking events based on irreversibility and artifact ratios.
Interactive UI: A browser-based dashboard where you can visualize the "moment of decay" and run audits on raw CSV data.

Final Thoughts

Is there a "Death Signal"? I’m still auditing. But the journey has taught me that the most important signals are often the ones we accidentally filter out.

Explore the Code: [GitHub: https://github.com/DIMProductions/non-equilibrium-auditor]
Try the Lab: [Live Demo at https://non-equilibrium-auditor.dim.productions/]