Skip to content

Engine monitor

📋 Planned · v0.11.0

A spike from 60% to 95% CPU 30 seconds before the downbeat is something you want to see now, not discover when the audio drops out during the overture.

What it is

A widget you place on your Perform-mode layout (typically tucked into a corner) that surfaces everything the engine knows about itself. Two display modes:

  • Compact — single status pill: green/yellow/red dot + the worst-offending metric. Fits in a corner of a busy layout.
  • Expanded — the full field table below. For when you have screen space and want the full picture.

Tap/click toggles between them.

Full field table

FieldSourceCompactExpanded
CPU % (overall)OS process stats✅ single number + 60s sparkline
CPU % (per plugin)Per-thread sampling✅ collapsed by default; expandable
RAM (resident overall)OS process stats
RAM (per plugin)Sandbox process stats (post-v0.7.0)✅ once sandboxing lands
Audio xruns / dropoutscpal callback overrun countercritical metric
Audio peak / clip per outputPer-output meter
Audio roundtrip latencyBuffer size × sample rate calc✅ single ms number
MIDI input activity per deviceEvent-rate counter✅ small activity light per device
Plugin status per pluginSandbox supervisor heartbeat✅ alive / quarantined / crashed
Plugin crash count (session)Counter✅ red if > 0
Uptime since Go LiveCounter
Disk I/O (backing tracks)Per-track byte counter✅ only when backing tracks active

What’s deliberately not on the list

  • Thermal pressure / CPU temperature — fragile cross-platform (macOS vs Windows vs Linux differ wildly), more hassle than it’s worth, and “engine got hot” is not a useful signal mid-show. By the time it matters, the dropouts have already happened.
  • Network status — Pit is local-first. Nothing performance-critical depends on network.

Color thresholds

Traffic-light colors. Unambiguous at-a-glance.

Metric🟢 Green🟡 Yellow🔴 Red
CPU< 50%50–80%> 80%
RAM< 4 GB4–6 GB> 6 GB
Xruns (this session)01–5> 5
Peak (dBFS)< −6−6 to −3> −3
Latency (ms)< 1010–20> 20
Crash count01≥ 2 (quarantine kicks in)

Thresholds customizable per-show in the widget settings.

Compact mode pill

The compact display is a single horizontal pill:

🟢 CPU 42% · 0 xrun · 8ms

When something goes yellow or red, the pill switches to that field as the headline:

🟡 CPU 78% · 0 xrun · 8ms # CPU yellow
🔴 1 xrun · CPU 65% · 8ms # xrun count red

The worst-priority metric wins. Tap to expand.

Reactive behavior

  • Engine pushes metrics via Tauri events at 10 Hz
  • Plugin status comes from the watchdog (introduced in v0.7.0 sandboxing)
  • Latency value comes from the same path as the latency display in audio settings
  • MIDI activity is fed from the per-device input thread (v0.6.0 hardware MIDI binding)
  • Sandboxing-dependent fields populate after v0.7.0 ships

Why this matters mid-show

Live performance is unforgiving. A musician can’t pause the show to check Activity Monitor. The monitor puts the signals in their eye line:

  • MIDI activity dots tell you instantly whether a stuck note is hardware (no dot) or software (dot, no sound)
  • Xruns climbing during a song means buffer is undersized for your current patch chain — change buffer next intermission
  • CPU sparkline showing growth over the show means a plugin is leaking somewhere — restart at intermission
  • Latency shifting mid-show means a device renegotiated — investigate immediately
  • Plugin status going red on a specific plugin tells you what to drop from your layout

These are the signals a working musician already mentally tracks — Stardust makes them visible instead of guessed.

Widget config

Per-widget options:

  • Mode — Compact / Expanded / Auto-collapse (compact unless an alert is active)
  • Show only critical metrics — toggle to hide everything but xruns + plugin status + latency
  • Threshold overrides — adjust green/yellow/red thresholds per metric
  • MIDI activity dots — show which devices (all / specific list / none)
  • Per-plugin breakdown — expand by default / collapse by default
  • Update rate — 10 Hz default; reduce to 1 Hz to save UI thread cycles on weaker hardware