GameCult/Mimir
Watch
9
0
Fork
You've already forked Mimir
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
Mimir/notes/current-system-map.md
Meta Vens f6b964a440 Bind Eve UI fields to CultCache paths
2026-06-01 17:43:00 +01:00

59 KiB
Raw Blame History

Current System Map

Source-level code ownership is mapped in docs/code-algorithm-map. The indexed problem-domain map is docs/perfect-machine-domain-index; the current architecture/optimization/sample-code study lives under research/perfect-machine-study-2026-05-23/.

Mimir is the public Face and product name for this repo. A few lower native ABI names still use localcast until a deliberate rename cut exists.

The live target is the native rolling field machine described in docs/native-rebuild-plan, docs/perfect-machine, and config/perfect-machine.example.json.

Perfect Machine Target

flowchart TD
    A["direct camera drivers"] --> R["Mimir.Runtime rolling buffers"]
    B["mic/loopback drivers"] --> R
    C["Leap timing/IR driver"] --> R
    D["network feed producers"] --> R
    R --> N["native reservoir handles"]
    N --> E["Fensalir GPU fusion + UI"]
    N --> F["Faust/native DSP"]
    E --> G["Spout2/program video"]
    E --> V["EVE native shared-texture stream"]
    F --> H["program stems + spatial bed"]
    G --> I["OBS"]
    H --> I

Ownership:

  • Mimir owns configuration, calibration truth, launch, status, persistence, and runtime contracts.
  • Mimir is a CultMesh app: typed state surfaces for codebooks, schedules, calibration receipts, path response, and offload work must be mesh-syncable so phones, microcontrollers, Raven, and Starfire can participate without becoming independent clock authorities.
  • Mimir.Runtime owns app-level stream buffers and synchronization.
  • Native capture workers own device reads.
  • Fensalir owns dense visual fusion, material/brush/splat reconciliation, D3D12 interop, runtime UI, Spout2 publication, and the completed backbuffer texture copied into the EVE shared D3D12 program-output surface.
  • Faust/native DSP owns hot audio alignment, suppression, separation, spatialization, and stem generation.
  • OBS owns broadcast controls.
  • EVE owns native decode/composite for its fullscreen display path; it does not own layout, WebKit compatibility, or timing authority.

Invariant: the live window is bounded, in memory, and has one timing authority. No private history outlives the rolling buffer.

Viable Stream App

docs/viable-stream-app defines the near-term app target. Fensalir hosts the running Mimir app, keeps the default five-second runtime in memory, exposes debug/settings/output controls, and emits synchronized OBS program video plus separately controllable audio stems.

Mimir.Runtime currently provides:

  • MimirSynchronizationHub;
  • MimirRollingStreamBuffer;
  • stream descriptors/settings;
  • IMimirStreamSource;
  • MimirNativeIngestStreamSource;
  • MimirProcessStreamSource;
  • MimirFrameEventProcessStreamSource;
  • MimirVideoFrameDescriptor;
  • MimirAudioSynchronizationAnalyzer;
  • IMimirVideoCaptureDriver;
  • MimirVideoCaptureDriverSource.

Process-backed sources are bridge/network edges. Local cameras should feed native descriptors with device timestamps and optional native/GPU handles. The frame-events/json-lines adapter is a diagnostic witness only: native probes can emit per-frame JSON metadata so Fensalir sees real sensor cadence in the rolling buffers while the direct ABI driver is being cut. It does not carry pixels and does not own the final six-camera hot path. Multi-camera probes are one process with declared accepted source ids, not one process per camera. The ffmpeg-rawvideo adapter is the live network-pixel edge for Raven setup: FFmpeg owns SRT receive/decode and writes exact raw frames to stdout; MimirFfmpegRawVideoStreamSource owns frame-boundary reads, BGRA/NV12 payload geometry, sample descriptors, and insertion into the normal synchronization path. config/mimir-runtime.raven-eve.example.json declares raven-display on SRT port 5200. EveCanvas owns Eve camera/mic capture directly and sends typed frame-events to Mimir.EveSensorReceiver on WebSocket ports 8793 and 8794.

OBS Bridge Utility

flowchart TD
    A["config/localcast.json"] --> B["sender-start.ps1"]
    C["FFmpeg on sender"] --> D["Windows desktop capture"]
    C --> E["DirectShow audio capture"]
    D --> F["NVENC encode"]
    E --> G["audio encode"]
    F --> H["SRT video endpoint"]
    G --> I["SRT audio endpoint(s)"]
    H --> J["OBS Media Source"]
    I --> K["OBS Media Source per audio source"]

The bridge is useful because it is inspectable and already speaks OBS. It does not become the synchronized program authority.

Audio Field

The six-microphone path is separate from the bridge. Current local routing is: Windows system default output is Scarlett for monitoring, while Starfire Realtek is the active chirp-emission and loopback-measurement path. Any active chirp runner that emits to the default output is therefore wrong unless it explicitly selects Realtek. Scarlett production capture belongs on ASIO rather than WASAPI shared mode, and Scarlett remains the professional mic/monitor interface rather than the current chirp speaker authority. MimirBioacousticTimeline owns the active runtime watermark described in docs/bioacoustic-timeline-watermark: a low-gain birdsong-like word language with 128 self-identifying word positions, left-speaker and right-speaker variants, four formant-rich syllables per word, rhythm variation, and direct word identity. Any correctly decoded word identifies the event index inside the current operating horizon. Mimir queues the left vocabulary to the left speaker and the right vocabulary to the right speaker through Fensalir audio, then decodes timing as bioacoustic evidence. MimirAudioSynchronizationSettings.Mode chooses whether active calibration is allowed: chirp-only emits the active bioacoustic witness, passive stays silent and uses program-audio phase correlation, and hybrid uses passive evidence by default while emitting active pilot chunks only when passive confidence is weak. Active decoding does not inherit the passive two-second analysis floor: passive still needs a longer program-audio window, while the bioacoustic witness can decode once at least one self-identifying song word is present. The active decoder is a song-contour anchor machine, not a de Bruijn sequence receiver: one call carries enough contour, syllable timing, formant, payload, rhythm, and speaker-tint evidence to identify canonical time inside the operating horizon and pin multiple time/frequency anchors at once. The bioacoustic detector now uses bounded motif proposals, matched motif scoring, direct word anchors, source clock fitting, and fractional waveform refinement. Pairwise sync compares matched anchors first, then only accepts independent clock-fit offsets inside the live latency horizon so period aliases do not become absurd reports. The old chirp-bin detector remains as a calibration/reference artifact: it carries the full dechirped bin-energy surface and aggregates decodes into a MimirChirpBinCalibrationModel with measured usable bands, expected-symbol versus observed-bin confusion observations, timing residuals, delay hypotheses, phase summaries, and an adaptive codebook plan. The analyzer keeps raw profiles even when no timing report is accepted, so physical mic failures can still guide bioacoustic motif weighting. Reports/states expose delayUs next to fractional sample delay. Mimir.BufferSmoke --bioacoustic-self-test proves direct word anchors. --standalone-bioacoustic-self-test --sample-rate 48000 --delay-samples 1269.5 proves a receiver with only codebook/schedule state can recover delayed source time to below printed microsecond precision. --chirp-only-sync-self-test --sample-rate 48000 recovers a 317.375-sample synthetic delay with printed 0.000 us error using evidence=bioacoustic. --bioacoustic-train is now the receipt-backed tuning harness: it runs multiple indexed cepstral decoder hypotheses across mel-cepstral warp/blur degradations and writes typed CultCache results plus pre-warp, post-warp, and reconstructed-from-detections WAV artifacts. The latest local receipt under artifacts/bioacoustic-training/bioacoustic-20260524-103438/ shows identity survives many degradations, but timing still fails under warped domains, so the next receiver cut is a global delay/clock/path hypothesis over detected words. Reports now carry fractional delay and per-band matched energy. The older MimirChirpletSymbolCodebook / MimirChirpletStreamDecoder path remains a diagnostic reference for constrained chirplet-transform work. The active receiver is the bioacoustic motif timeline; the analyzer only emits active timing reports from matched canonical anchors. The hub also owns cached reports plus smoothed per-source sync state with delay-slope/SRO in ppm. MimirRuntime runs analysis online as a bounded rotating service and can print live telemetry with MIMIR_SYNC_TELEMETRY_SECONDS. UI and telemetry are passive readers of cached sync state; they must not invoke the analyzer. Current app testing proves loopback wakeup, live mic buffers, and confident online sync states, but the next proof is stable canonical anchors through real mic streams. Camera mics are spatial/context witnesses; Focusrite devices are dialogue anchors. Fractional delay and the hot resampler belong in Faust/native DSP.

The WASAPI cadence probe is now a format/state diagnostic: it can request shared or exclusive sample rates, bit depths, channel counts, and float/PCM formats, then report the selected or closest format. The Focusrite driver stack is now installed and registers Focusrite USB ASIO. The Scarlett Solo 4th Gen is attached to Starfire and exposes 4 ASIO inputs / 2 outputs: Input 1, Input 2, Loopback 1, and Loopback 2. native/probes/asio_audio_cadence can instantiate that driver, verify 44.1-192 kHz support, and capture nonzero 4-channel Int32LSB callbacks at 192 kHz with 192-frame preferred buffers. The runtime analyzer accepts Float32, Int16, Int24, and Int32 PCM windows so ASIO/native capture can preserve the interface format. Raven also has a loopback-capable Scarlett ASIO path at 192 kHz for co-streamer/game timing evidence; Starfire still owns the heavy soundfield and sensor-fusion work. The ASIO probe can now play raw mono Float32 timeline audio through the Focusrite outputs while capturing every ASIO input as raw interleaved Float32. Mimir.BufferSmoke --analyze-asio-f32 feeds those captured channels into the same runtime analyzer. --calibrate-chirp-bin-asio-f32 computes and persists the response/confusion/delay model per output/mic path, and --analyze-asio-f32 --calibration ... loads it into the chirp-bin reference decoder. native/asio_capture and MimirAsioStreamSource are now the runtime Scarlett path: Focusrite ASIO callbacks feed sample-bearing 192 kHz Float32 blocks into Mimir.Runtime in process, without the diagnostic JSON/stdout bridge. The minimal config/mimir-runtime.asio.example.json proof ingested more than 12,000 sample-bearing 192 kHz blocks across asio-ch0 through asio-ch3 in two seconds and retained 2,048 blocks per channel, all from the same ASIO callback stream. A real 192 kHz chirp-bin Scarlett artifact decoded Loopback 1 -> Loopback 2 at exactly 0.000 us with 12 matched anchors and 0.999 confidence. The same analyzer now prints calibration profiles for decoded sources. Physical input 1 still fails pairwise timing in the stored artifact, but it leaves a concrete response profile: 14 frames, 12 anchors, 0.865 clock confidence, and strongest bins around 4525, 4075, and 7225 Hz. Acoustic robustness is now the open problem, not clean loopback timing, standalone decoder shape, or basic response evidence. Mimir.BufferSmoke --calibrate-contestant-asio-f32 now owns the active packet-song physical calibration receipt. It runs the canary packet decoder against interleaved ASIO Float32 captures, performs a fast per-channel global delay hypothesis search, then tight scheduled packet scoring with sub-sample refinement. The latest persisted model at calibration/bioacoustic/scarlett-canary-packet-192k-rerun.json ran at 10.7x realtime across four 192 kHz channels and records per-channel polarity, schedule offset, payload reliability, gain, response-normalization bands, and pairwise propagation delay. Current physical precision is loopback 2.524 us MAE, co-streamer shotgun 58.785 us MAE, and cardioid 90.558 us MAE; do not claim physical microsecond sync until those mic MAEs collapse by another order of magnitude. A fresh 192 kHz room run after the song-contour authority cut is persisted at calibration/bioacoustic/scarlett-canary-packet-192k-contour-fresh.json. It clears the 10x realtime budget, keeps loopback at 2.524 us MAE, improves the co-streamer shotgun to 37/37 payload with 34.083 us MAE, and improves the cardioid event count to 31/37 while still measuring 92.996 us MAE. The next precision cut must extract intra-call contour anchors, not only one offset per packet word. The first anchor-rich canary packet is persisted at calibration/bioacoustic/scarlett-canary-packet-anchor-rich-192k.json. It adds timing chips, formant pivots, harmonic-envelope notches, payload ornaments, renderer-level template caching, and per-event intra-call anchor measurements. It clears 10x realtime and improves loopback to about 2.23 us MAE, but physical mics do not improve yet: shotgun is 36/37 payload at 56.365 us MAE and cardioid is 27/37 payload at 101.522 us MAE. Treat this as anchor observability, not a finished anchor geometry. The next cut should learn which anchor kinds survive each acoustic path and weight or reshape them. Path-level loopback truth is now part of the calibration receipt: candidate mic anchors are matched against loopback anchors, then event-local waveform correlation against the captured loopback packet refines path delay. On the stored anchor-rich capture this improves physical path precision to 7.576 us for the cardioid and 6.578 us for the shotgun while Release runs at 21.1x realtime. A fresh capture at calibration/bioacoustic/scarlett-canary-packet-anchor-rich-latest-192k.json keeps the shotgun around 5.916 us but worsens the cardioid to 18.930 us. The rejected razor timing-chip mutation made the mics worse and should not be revived without a better hypothesis. The remaining gap to one microsecond is phase/group-delay correction or a more survivable direct-path anchor family. A naive recursive waveform phase-lock pass was also rejected: it improved one cardioid receipt but worsened the shotgun and locked a fresh cardioid run onto a later reflection lobe. Recursive refinement remains a good architecture only after the path model can distinguish direct arrival, phase/group delay, and room reflection energy. The follow-up sonar/DSP research note at research/sonar-dsp-recursive-refinement-2026-05-25.md maps that correction: use complex matched filters, phase-slope/group-delay fitting, acquisition versus tracking loop bandwidths, and sparse multipath residuals before attempting another recursive fitter. The first implementation slice now exists in MimirComplexContourMatchedFilterBank and MimirDirectPathTracker: known canary packet anchors become complex matched-filter responses with multiple candidate lobes, then the tracker uses the current path prediction as authority, selects the coherent direct-path cluster inside that gate, and reports later clusters as reflection taps. Synthetic 192 kHz reflection smoke currently lands about 5.249 us from the expected delay; stored Scarlett shotgun runs land within about 5.860 us and 7.247 us of the seeded path fits, while cardioid runs land within about 15.817 us and 8.963 us. This is the correct receiver shape, but not yet the final phase/group-delay channel model. The tracker now emits per-band delay/phase residual observations and has a MimirDirectPathChannelModel correction surface for later multi-window calibration; one-window self-correction is not allowed to become authority. calibration/bioacoustic/complex-contour-replay-panel.json is the current persisted receipt for this surface across stored/fresh shotgun/cardioid cases. MimirDirectPathChannelModel now applies learned per-band delay and phase correction when explicitly supplied, and downweights bands outside the learned usable surface. Mimir.BufferSmoke --learn-complex-contour-channel-model persists the current path-scoped model at calibration/bioacoustic/complex-contour-channel-model.json; it learns three usable cardioid bands and six usable shotgun bands from the four-case replay receipt. --evaluate-complex-contour-channel-model writes calibration/bioacoustic/complex-contour-channel-model-evaluation.json: the model improves 3/4 absolute path-seed errors and lowers mean cluster MAE, with the fresh cardioid reaching about 0.202 us from the seed, but the stored cardioid still worsens to about 17.476 us. Treat the model as explicit calibration evidence, not default runtime authority, until more captures prove the path surface stable. The complex contour receiver now has a live runtime lane instead of living only inside BufferSmoke artifact replay. When enableComplexContourRuntime is true, MimirRuntime emits the configured bioacousticWitnessProfileId through MimirBioacousticContestantRenderer, MimirSynchronizationHub loads complexContourChannelModelPath, and MimirComplexContourRuntimeAnalyzer extracts Float32 windows from rolling audio buffers to publish evidence=complex-contour reports. The synthetic runtime-shaped proof --complex-contour-runtime-self-test at 192 kHz recovers a 693.5-sample delay with about 0.219 us error from rolling buffers. The next real-world proof is to run that lane through live Scarlett loopback and mics, not only stored ASIO artifacts. MimirCalibratedAudioCompositeBuilder is the first C# diagnostic owner for turning that acoustic evidence into a corrected composite stream. It consumes sample windows plus MimirAudioSynchronizationState delay/confidence and per-band response evidence, applies fractional alignment, sparse measured-band equalization, calibrated-band coherence scoring, incoherent-band suppression, and confidence/noise-weighted summing, then emits composite samples plus source flatness/weight/coherence reports and per-band coherence/suppression reports. This is not the hot room-DSP authority and it does not make room nulls disappear; Faust/native DSP still owns the production alignment, suppression, separation, and stem lane. Mimir.BufferSmoke --calibrated-audio-composite-smoke proves the contract on synthetic delayed, colored, noisy mic paths: the uncalibrated mix measures -3.171 dB SNR, the calibrated composite measures 15.135 dB SNR, and response flatness improves from 0.548 to 1.000. Mimir.BufferSmoke --dual-mic-coherence-cancellation-smoke proves the two-witness cancellation cut: shared tones keep about 0.999 coherence, a mic-local 3.52 kHz interferer scores about 0.001 coherence and 0.948 suppression, its measured energy falls from 0.039195 to 0.001306, and SNR rises from 1.366 dB to 16.304 dB. scripts/record-kiyo-dual-mic-composite.ps1 is the first listenable Faust-chain bridge receipt for that path. It starts Kiyo FFmpeg capture and Scarlett ASIO raw capture together, converts ASIO channels 0/1 through --asio-dual-mic-faust-cleaner-wav, and muxes the Faust dialogue WAV with Kiyo video. The offline command compiles/runs faust/mimir_alignment_actuator.dsp first, then feeds the aligned shotgun/cardioid stems into faust/mimir_dual_mic_dialogue_cleaner.dsp; the older C# composite stays a scoring/audition contract, not the current listening receipt. The fresh 2026-06-01 receipt at artifacts/runtime/kiyo-dual-mic-composite/20260601-051044 and artifacts/runtime/kiyo-dual-mic-composite/kiyo-dual-mic-composite-latest.mp4 has 10.000 s of 640x480 30 fps Kiyo video and 10.000 s of 48 kHz mono AAC from the Faust dialogue stem. It estimated the cardioid 359.398 samples late (7487.452 us), applied holdback 359.398/0.000 samples to shotgun/cardioid, and wrote both dialogue and residual WAVs. The first muxed receipt was nearly silent because NormalizePeak only attenuated hot samples; after the helper was fixed to amplify quiet receipts too, the regenerated dialogue WAV peaks at -0.724 dBFS with RMS -14.202 dBFS. The actual denoise authority is Faust: faust/mimir_dual_mic_dialogue_cleaner.dsp compiles as a two-input/two-output aligned shotgun/cardioid dialogue cleaner with smooth multiband voice shaping, witness subtraction, and slow downward expansion. MimirRuntime queues it as dual-mic-dialogue-cleaner with host_voice and residual ambient output stems. It is fed from the alignment actuator's published aligned_source_* stem frame, not from raw mic buffers, so Faust alignment is a real structural precursor to cleanup. Mimir.BufferSmoke --dialogue-cleaner-routing-smoke proves the boundary: alignment frames queue the cleaner DSP and input block, and cleaner output frames are what enter NativeProgram stem publication. This is the first hot-lane cleaner socket, not proof that the final studio denoiser is solved. The right rail Output panel is the app feature for local broadcast-proof recording and live publish control, not the isolated Kiyo/Faust mic receipt. MimirProgramRecorder owns Record / Stop, child-process status, timestamped MP4 receipts under C:\Users\Meta\Videos\Mimir by default, and process-tree shutdown. Its current actuator is scripts/record-stream-proof-output.ps1, so app recording produces the same stream-proof composite intended for Yggdrasil/public judgment: Raven program feed, Kiyo picture-in-picture, Starfire Scarlett audio, and NVENC/AAC broadcast settings. MIMIR_RECORD_START_RAVEN=1 asks the app to start Raven's sender for the receipt. MimirProgramStreamer owns Live / Stop for the Mimir.Broadcast RTMP path; it requires MIMIR_STREAM_INPUT unless MIMIR_STREAM_ALLOW_TEST_PATTERN=1 explicitly authorizes a synthetic smoke stream. Later native recording/streaming should replace these actuators behind this owner, not add another UI truth. MimirTargetedBioacousticProbePlanner is the matching "ask the room a better question" owner. It consumes per-source spectral residuals and optional source pathology notes, then emits gain-bounded shaped probe bands for the bioacoustic renderer to spend energy on. The first smoke models the two professional 192 kHz Scarlett mics only: asio-ch0-shotgun is explicitly noisy and low-heavy, asio-ch1-cardioid is cleaner, and the planner prioritizes the shotgun's weak/unmeasured high-band evidence before lower residuals. Mimir.BufferSmoke --targeted-bioacoustic-probe-smoke selects four probe bands, led by about 18.6 kHz as an unmeasured band at the max bounded gain, then about 9.9 kHz weak response, 3.6 kHz phase instability, and 910 Hz magnitude residual. This is the intended first physical strategy: improve shotgun/cardioid confidence at 192 kHz before asking every connected mic to help solve the room field. MimirBioacousticProbeScheduler now owns the first closed-loop cadence layer above that planner. It reads smoothed sync states plus derived per-band frequency-response residuals from MimirSynchronizationHub, backs probe cadence off as aggregate sync/frequency confidence rises, emits targeted probe plans only when the confidence/duty budget says to spend sound, and exposes mimir-bioacoustic-probe-schedule plus per-source telemetry in MimirRuntime. Mimir.BufferSmoke --bioacoustic-probe-scheduler-smoke proves the visible climb: simulated probe feedback raises sync confidence from 0.360 to 0.920 and frequency-response confidence from 0.558 to 0.955 over four scheduled probes. The scheduler is not the output-device authority; in the current physical routing the eventual live renderer must explicitly select Starfire Realtek. That Realtek renderer now exists as a tooling edge. Mimir.WasapiLoopback targets net10.0-windows, enumerates active render endpoints, selects by friendly-name substring, and can play mono Float32 probe audio through the matched WASAPI render endpoint. Mimir.BufferSmoke --targeted-bioacoustic-probe-realtk-live renders a targeted probe, starts Scarlett ASIO capture, plays it through the selected Realtek speaker endpoint, then scores the captured shotgun/cardioid response. The first proof selected Speakers (Realtek(R) Audio) and wrote artifacts/wasapi/targeted-bioacoustic-realtk-live/20260601-033851; at gain 0.75 the shotgun peak was 0.407887 and cardioid peak was 0.074494, but 18.6 kHz remained near-zero confidence while cardioid 3.6 kHz was the strongest printed band at 0.098 confidence. Realtek emission is now real; high-band probe choice is still a bad physical question for this room/speaker path. The default targeted probe planner now caps selection at 12 kHz and biases measurable low/mid bands instead of favoring ultrasonic-ish uncertainty that ordinary speakers and mics cannot answer well. The calibration runner is now closed-loop instead of a blind full-spectrum sweep: --bioacoustic-realtk-scheduled-calibration-live asks the scheduler for each probe, emits through Realtek, captures Scarlett, updates residuals, and then asks the scheduler again. It is a live physical I/O diagnostic harness seeded from the current Scarlett residual model; production still needs measured runtime confidence state wired into the same scheduler/emitter path. The 2026-06-01 receipt at artifacts/wasapi/realtk-scheduled-calibration-live/20260601-035354 ran four scheduled steps at gain 1.15 and wrote scheduled-response-bands.csv plus balance-plan.md. Local peak-vs-percentile-floor scoring found strong usable response near 910 Hz, 3.6 kHz, and 9.84-9.87 kHz on both Scarlett mics. The scheduler now filters confidence/status to the same 120 Hz-12 kHz schedulable window as the targeted planner, so old 18.5 kHz residual scars can remain recorded without owning live cadence or weakest-band status. The first live run preserves two artifacts: artifacts/asio/targeted-bioacoustic-live/20260601-030836 at playback gain 1.0 and artifacts/asio/targeted-bioacoustic-live/20260601-030857 at gain 2.0. Loopback energy scaled, but 18.6 kHz stayed nearly absent in the physical mics; the second pass measured shotgun -51.475 dB and cardioid -56.585 dB relative to loopback at that band. The 910 Hz probe was strongest physically, especially shotgun at -21.994 dB relative to loopback. Current high-band probing should be treated as failed path evidence, not a calibration win. Louder follow-ups at gain 4 and gain 8 stayed below clipping; gain 8 reached shotgun peak 0.140715 and cardioid peak 0.027774. Even then, 18.6 kHz remained unusable at shotgun -54.910 dB and cardioid -63.258 dB relative to loopback. Bias the next probe language toward usable low/mid anchors unless the speaker, mic placement, or output path changes enough to make high-band evidence real. That real-world proof now has a first receipt: calibration/bioacoustic/complex-contour-live-20260525-063229.md. A freshly rendered canary-packet witness was played through Focusrite ASIO and captured from all four 192 kHz Scarlett inputs. Loopback 1 to Loopback 2 measured -0.014 us, the shotgun path landed -3.984 us from its prior path seed, and the cardioid path landed +1.547 us from its prior path seed with the current channel model loaded. This proves the contour/channel-model path survives a fresh DAC/speaker/room/mic/ADC pass, but low physical confidence means the next cut is stronger direct-path confidence and independently measured path truth, not a victory lap. A follow-up receipt, calibration/bioacoustic/complex-contour-live-20260528-002313.md, keeps the interface loopback proof healthy: asio-ch2 to asio-ch3 measured -0.062 us with 0.956 confidence and 257 direct hits. Physical inputs are not currently usable timing signals: asio-ch0 and asio-ch1 produced zero contour hits against 1480 reference hits, with very low RMS. The next physical proof is blocked on mic gain/routing/source placement before receiver logic changes. After arming both mics, complex-contour-live-20260528-080604.md showed both physical inputs were alive but was accidentally routed to headphones. The monitor-routed proof complex-contour-live-20260528-080727.md is the first credible fresh physical contour receipt: loopback is -0.014 us at 0.971 confidence, asio-ch0 lands -0.410 us from its stored path seed at 0.524 confidence with 24 direct hits, and asio-ch1 lands -2.467 us at 0.363 confidence with 14 direct hits. User-provided physical mapping: asio-ch0 is the shotgun, about 1.5 m from the right monitor and 3.0 m from the left; asio-ch1 is the cardioid, about 0.5 m from the left monitor and 1.5 m from the right. Repeat captures are needed before updating the channel model or letting physical mic reports drive actuator authority. complex-contour-monitor-split-20260528-081813.md adds --play-output-channel to the ASIO probe and captures output 0 and output 1 separately. Loopback proves the ASIO output buffers are distinct, but physical mic delays are nearly identical across outputs: shotgun differs by about 20.885 us and cardioid by about 24.789 us. That does not match the declared left/right monitor geometry, so the downstream monitor path is probably summing, mirroring, or otherwise not isolating the physical speakers. The first actuator proof now exists: faust/mimir_alignment_actuator.dsp owns six channels of bounded fractional delay/gain controls for Faust/native DSP, and Mimir.BufferSmoke --bioacoustic-actuator-self-test --sample-rate 48000 --delay-samples 317.375 proves the control loop shape by estimating a bioacoustic delay, applying fractional correction, and remeasuring residual below printed microsecond precision. MimirAlignmentActuatorBank is now the runtime command owner above that Faust surface: it converts smoothed sync states into nonnegative holdback commands, keeps source-to-sourceN slots stable, reports overflow beyond the six-source profile, and exposes the reference holdback separately. MimirRuntime updates that command frame on the sync analysis cadence, queues it into AquariumAudioDocument as an engine audio control frame, declares faust/mimir_alignment_actuator.dsp as an AquariumStreamingDspProgram, and telemetry can print the current DSP targets. Mimir also queues sample-bearing AquariumStreamingAudioBlock lanes from the latest actuator source buffers, using the bank-assigned Faust sourceN control path as channel authority. Fensalir can compile/host/process that persistent Faust graph now. The engine now publishes processed output lanes as AquariumAudioStemFrame records through IAquariumAudioStemBus, with Mimir's actuator program declaring deterministic aligned-source stem names. OBS-facing publication now has a first readiness surface: MimirObsStemPublicationState consumes those frames without copying audio and reports ready, missing, and unconfigured stems against the alignment actuator stem-bus profile. MimirObsStemSharedMemoryPublisher writes the validated stem frames into Local\MimirObsStemBus, and native/obs_stem_source is the first OBS source plugin bundle: Mimir Audio Stem reads one named stem from that map and submits it through libobs audio, while Mimir Program Texture opens Fensalir's named shared D3D12 program-output texture and draws it through an OBS-readable shared D3D11 bridge texture. The video path is GPU-to-GPU and does not require Spout2 or CPU readback; the remaining copy is the explicit D3D12 to libobs-D3D11 boundary. Fensalir publishes Global\MimirFensalirProgramFence as a program-output publication fence, and the OBS source opens that fence before copying. This prevents blind read-before-producer-completion without coupling OBS to Fensalir's private frame fence. An optional texture ring is available when Fensalir and OBS agree on FENSALIR_PROGRAM_OUTPUT_RING_COUNT; OBS selects the latest completed slot from the program-output fence value. OBS can publish Global\MimirObsProgramConsumerFence; when Fensalir is launched with FENSALIR_PROGRAM_OUTPUT_CONSUMER_FENCE_NAME pointing at that fence, it skips publication instead of reusing a ring slot OBS has not acknowledged. scripts/build-obs-stem-plugin.ps1 stages the upstream OBS plugin-template SDK under artifacts/obs-sdk/ and builds the plugin DLL locally. The rendering migration's program-output receipt phase is structurally complete: OBS consumes final Mimir/Fensalir surfaces and stems through the native plugin, raw feeds remain debug inputs, and the ledger records the live program texture, texture ring, dedicated producer fence, and consumer-fence proofs. The public self-hosted edge has its first deployable path. src/Mimir.Broadcast builds the Starfire-side FFmpeg/NVENC push command for rtmp://127.0.0.1:11935/live/mimir; the port is an SSH local forward to Yggdrasil's localhost RTMP listener. Yggdrasil owns nginx RTMP ingest and HLS segment serving only. It must not transcode or compose in v1. The public static viewer route is https://gamecult.org/livestream, owned by the root gamecult-site repo, and it reads https://streampixels.gamecult.org/mimir/live/hls/mimir.m3u8. On 2026-05-30 the deployed Yggdrasil origin validated nginx, listened on 127.0.0.1:1935, returned mimir-live-ok, and generated four HLS segments plus mimir.m3u8 from an eight-second Starfire synthetic NVENC push. live.mimir.gamecult.org is no longer required for v1 because StreamPixels already has DNS and TLS on Yggdrasil, and Mimir's own static site does not own the viewer. MimirSynchronizedBufferPlanner is now the low-level aligned-buffer primitive: it picks one canonical presentation time inside the retained rolling window and returns per-stream slices for cameras, network display feeds, and audio. Timing corrections may target either one source or a shared clockDomainId. The Raven shape is explicit: Raven controls both display pixels and an audio timing signal routed into Scarlett, so Scarlett-decoded Raven audio evidence can earn a raven-sync correction that is applied to the raven-display buffer. Network arrival timestamps remain metadata, not timing authority. The first operational ingest config is config/mimir-runtime.raven-eve.example.json: Raven screen capture arrives over SRT and decodes to raw BGRA through FFmpeg; Eve camera/mic arrive as EveCanvas-native WebSocket frame-events. All three enter the same rolling-buffer model as local sources. Eve's sensor authority now lives in EveCanvas, not an external camera-streaming app. MimirPresentationControlState now owns the Fensalir program-control intent: video feed visibility/solo/opacity/layer order, audio mute/solo/gain, and global LUT preset selection. The Mimir Program panel exposes those controls without giving OBS or bridge endpoints composition authority. Video controls filter production surface intents before Fensalir composition; audio controls modify Faust gain controls and sample gain before Fensalir streaming DSP. LUT presets are typed postprocess state, with exposure/bloom currently mapped into GraphicsSettings and LUT texture sampling left as the next renderer hook. MimirSceneEditorState is now the separate Mimir-window editor owner. It owns the editor camera, dynamic scene nodes, selected node, visibility/lock state, 2D-plane transforms, reset commands, and grab/rotate/resize gizmo mode. Rolling video buffers derive sensor-feed panel nodes; SDF text panels and model import requests create editor graph nodes. MimirRuntime presents that editor through the Fensalir camera plus derived spline outlines, selection handles, and the Mimir Editor hierarchy/transform panel. The center preview requests a Fensalir-owned blit of the current output buffer, then draws Mimir's normalized placement overlays on top. This editor is not the OBS program output authority; it is a live program-surface witness. The placement commit primitive keeps layers inside the program frame, snaps near edges/center, and preserves source aspect while resizing through direct preview handles, sliders, or the scale gizmo. Explicit transform/source controls are inspector-only and gated to a selected program source; the center canvas handles are the primary compositor edit path. Empty-canvas clicks clear source selection; hover/active handles and snap guides come from the shared Eve dashboard document state that Fensalir's Direct2D and D3D12 paths lower locally; arrows nudge the selected layer, PageUp/PageDown reorder layers, and the inspector owns the selected source contain/cover/stretch fit mode. Eve is the portable dashboard authority, while CultUI is only the C# reference API shape for the document. The shared element contract now includes typed CultCache/CultMesh field bindings: document schema/id, field path, value kind, access, authority, and optional command id. Callbacks are native lowering actuators; the binding is the portable Verse-backed state contract. World SDF glyph rendering, ASSIMP-style mesh decoding/upload, and pixel-accurate gizmo hit-testing are explicit Fensalir renderer cuts, mapped in docs/scene-editor-control-surface. Mimir.EveDashboard is now a small native Eve dashboard broker. It serves /eve/deck plus the compatibility /eve/dashboard endpoint, exposes provider manifests at /eve/deck/providers, and routes retained dashboard snapshots and commands for provider-owned trees. Built-in providers are the switchboard, mimir.stream.layout, voidbot.swarm, and yggdrasil.streampixels.edge; launch-time external providers can be registered as id|title|ws-url descriptors for LAN or SSH-forwarded TCP surfaces. EveCanvas renders the dashboard locally in UIKit, including the scene graph and multitouch pan/pinch/rotate source panels, and now treats provider-card taps as open-provider commands. voidbot.swarm reads VoidBot's existing .voidbot/status/swarm-state.json projection, publishes avatar URLs on identity nodes, and Eve renders a native VoidBot-style cockpit: CTB rail, selected Face/status pane, state tree, and detail panel. Dashboard manifests and states have typed CultMesh-compatible document shapes mimir.eve_dashboard_manifest.v1 and mimir.eve_dashboard_state.v1, while the live iPad lane remains WebSocket/TCP because it is the proven tunnelable transport. mimir.eve_dashboard_state.v1 now mirrors each retained element's optional binding object so clients can move fields into CultCache without turning bindNodeId into a second authority. The Mimir stream-layout provider still uses fixture state; the next cut is binding it to live MimirPresentationControlState and MimirSceneEditorState.

Visual Fusion

Visual fusion belongs in Fensalir over current reservoir claims. Native capture workers provide frames; Fensalir owns feature extraction, matching, material fitting, render budgeting, and publication.

Fast stereo depth is now mapped as a future Fensalir D3D12 compute lane, not an external library dependency. The provenance note research/d3d12-stereo-depth-provenance-2026-05-29.md records libSGM as the current permissive north-star reference: Mimir/Fensalir should rebuild the SGM shape over synchronized rectified texture pairs, calibration state, typed GPU resources, and explicit fences. CUDA, TensorRT, and monocular depth demos remain research references only. The first live contract exists: MimirStereoDepthConfigurations names the libSGM-provenance D3D12 SGM profile, and MimirFensalirFieldLowering.BuildStereoDepthCandidateFrame lowers caller- declared rectified stereo input textures into a GPU-resident compute-writable disparity SurfacePage, confidence texture, Height FieldEvidence claim, and AquariumFieldStereoDepthLowering sidecar. The live BuildLeapPackedStereoDepthCandidateFrame path now recognizes a live LeapStereoIr rolling video window, reuses its declared packed R8G8 texture as both left and right resource identity, names the left/right observations as packed R/G lanes, and emits the same depth lowering automatically from the runtime frame. The lowering sidecar is the dispatch contract: it binds the libSGM-provenance profile, calibration id, camera pair, inputs, disparity output, min disparity, disparity levels, aggregation paths, census radius, P1/P2 smoothness penalties, and depth range. The current D3D12 SGM profile publishes min disparity 0, 128 disparities, four paths, census radius 2, P1 8, and P2 96. Fensalir now has a first packed-Leap D3D12 kernel that writes R16F disparity through a crude SAD/block-match pass. This is intentionally a small kernel-shaped proof, not full libSGM-style SGM or calibrated metric depth yet. The first point-cloud root is also code-visible now: MimirPointCloudConfigurations.LeapDisparityPointCloudRoot records the stereo-disparity projection profile and provenance, while MimirFensalirFieldLowering.BuildLeapPackedStereoPointCloudCandidateFrame declares a GPU-resident FieldMesh point-list resource derived from the Leap R16F disparity SurfacePage. MimirRuntime merges that Mesh claim into the same evidence frame as the Leap stereo-depth lowering. Mimir.BufferSmoke --leap-point-cloud-root-smoke proves the combined depth/point-cloud contract plans as one SurfacePage packet and one Mesh packet with zero deferred requests. Fensalir branch codex/leap-packed-depth now has the first native surface-claim lane too. It preserves Mesh SourceUri=derived-from:*, allocates generated point-list vertex/index buffers as UAV-capable GPU resources, fills them from the disparity SurfacePage in D3D12PointCloudFromDisparityCS, and writes approximated normals, curvature, SDF, PBR, and radiosity reservoirs into the existing fractal splat buffers. The point-list draw path is diagnostic-only; the verified live presentation path is Fensalir's splat/reservoir resolver. The 2026-05-31 live capture artifacts/runtime/mimir-leap-surface-claims-clean.png proves the clean path: LeapUVC frames uploaded through a Fensalir-owned D3D12 texture, packed stereo dispatched to R16F disparity, point-cloud compute generated 19,200 surface claims, the point-list mesh renderer stayed at rendered 0, and the reservoir resolver presented visible Leap-derived splats. The follow-up artifacts/runtime/mimir-leap-history-split-shader-visible.png proves the history pass now starts without AQUARIUM_DISABLE_RESERVOIR_HISTORY: Fensalir compiles a dedicated lean D3D12ReservoirHistoryUpdate.hlsl and writes the current resolver sample into the four-row history/resolved target. Temporal and spatial reuse are deliberately not restored in that lean shader yet; the remaining truth gaps are calibrated projection constants, full SGM, temporal reservoir reuse split into a compilable shader, and a global residual/calibration owner.

Fensalir must not be treated as a traditional rendering pipeline. Mimir does not ask it to "draw a thing" and hope post-processing makes the result true. Mimir submits evidence, buffers, constraints, and surface intent; Fensalir lowers those into field claims with travel/depth, metadata, control, and reservoir-guide lanes. If a path only paints pixels, it is a fallback/debug draw, not the Perfect Machine surface.

The live payload boundary is now explicit. Mimir declares each live native/GPU payload view as an AquariumFieldResourceDeclaration with resource key, kind, residency, shader access, format, shape, valid time range, version, and native handle metadata. Field claims and lowering requests reference those mimir:resource:* keys. The handle string is only a name; Fensalir validation, planning, and renderer-owned resource slots own typed resource resolution before shader lowering. Mimir-declared rendering buffers are Fensalir GPU resources in the same runtime; native/shared handle metadata is an import edge, not a separate authority regime. Rendering-relevant buffers move to GPU residency as early as possible and stay there; CPU readback/tessellation is diagnostic only. Camera descriptors now enter this bridge too. The preferred hot path is Fensalir-owned texture leasing: the runtime receives AquariumRuntimeServices, asks Fensalir's field resource broker for a keyed D3D12 Texture2D lease, the camera/decode producer writes that shared texture and signals the producer fence, then Mimir carries the same resource key through FieldEvidence. Fensalir waits on committed producer fence values before resolving shader reads. Shared foreign texture handles remain an import edge, not the primary camera authority. MimirVideoCaptureDriverSource propagates the lease client to drivers that implement IMimirFensalirTextureLeaseReceiver, so direct camera drivers can request the destination texture before emitting a frame descriptor. Each camera backend must use the closest-to-device path available and expose its unavoidable copy count. Managed/process wrappers are diagnostic bring-up surfaces, not the production camera hot path. For raw single-plane system-memory frames, MimirVideoCaptureDriverSource performs the one declared CPU-to-GPU upload into the Fensalir lease, drops the managed payload from the live sample, and increments UnavoidableCopyCount. NV12 CPU upload is rejected until Fensalir owns a real planar upload path; device/GPU NV12 producers should write the leased texture directly. MimirKsVideoCaptureDriver plus native/camera_capture/mimir_camera_capture.dll is the first production-shaped KS/UVC driver: it opens a Kernel Streaming pin in process, queues uncompressed UVC frames, and feeds the same IMimirVideoCaptureDriver source path. MJPG/H264 still need a device/GPU decode producer; the KS driver rejects compressed capture formats. MimirPs3EyeVideoCaptureDriver plus native/camera_capture/mimir_ps3eye_capture.dll does the same for PS3 Eye raw WinUSB/libusb capture, emitting Bayer8 frames through the common upload lane. Driver smokes have pulled and uploaded real frames for LeapUVC 640x240 YUY2, both PS3 Eyes at 320x240 Bayer8, Kiyo Pro 1920x1080 YUY2, and regular Kiyo 640x480 YUY2. Regular Kiyo 1280x720 YUY2 did not open. config/mimir-runtime.perfect-machine.local.json is the current local all-sensor runtime profile: Leap packed stereo IR, both PS3 Eyes at 320x240@187, Kiyo Pro RGB, and regular Kiyo RGB. Mimir.BufferSmoke --perfect-machine-live-smoke opens all five video sources through the runtime, attaches Fensalir texture leases, and requires five camera Texture2D resources, one Leap stereo-depth lowering, one disparity SurfacePage, and one derived point-cloud Mesh. Fensalir now plans those camera Feature/SensorObservation claims through its GpuSensorFusion backend instead of deferring them, then derives compute input metadata and SRVs from resolved FieldEvidence Texture2D resources. The current dispatch samples LeapStereoIr, both Bayer8 PS3 Eyes, Kiyo Pro YUY2, and regular Kiyo YUY2. Fensalir binds YUY2 through the Microsoft-documented R8G8B8A8_UNORM SRV view over DXGI_FORMAT_YUY2 and decodes Y0/U/Y1/V in compute; packed camera video is not silently treated as ordinary RGBA. MimirMediaFoundationGpuVideoCaptureDriver plus native/camera_capture/mimir_mf_gpu_capture.dll is the compressed camera path: Media Foundation SourceReader runs with a D3D11 device manager, decodes MJPG or H264 camera frames on the GPU, copies the decoded GPU surface into a shared BGRA D3D11 texture, and publishes a shared-d3d11-texture handle with no live CPU payload bytes. Kiyo Pro 1920x1080 MJPG->RGB32 and H264->RGB32 smokes both produced valid GPU handles/resources. Direct NV12 shared texture creation failed in D3D11, so NV12 needs plane-aware interop or a GPU bridge-copy cut. Metadata-only cadence frames do not create camera surface intents or fake payload requests. The old direct AquariumGpuSensorFrame bridge proof has been removed from Mimir's active proof path. Camera image claims currently defer until Fensalir owns a selected visual-fusion lowering for camera textures. The current smokes prove planning, not visible packet rendering: --fensalir-field-evidence-smoke now produces one planned resource-backed TubeField packet from Mimir's spectrum intent, and --fensalir-field-dsl-resource-smoke proves the Fensalir DSL can bind the same kind of declared resource directly. --fensalir-camera-observation-smoke proves the camera observation/resource split. Fensalir now has the first D3D12 resolver cut for structured/curve buffers: it imports shared GPU buffers by handle and allocates engine-owned GPU slots only for Fensalir-produced resources. The DSL can describe a 2D rolling float buffer as Catmull-Rom XY tubes with modulo column addressing, amplitude power/normalization, radius, ramp texture path, and emission scale. Fensalir now resolves the first non-buffer resource family too: Texture2D local assets bind as TubeField ramps, surface pages and volume textures allocate shader-readable GPU textures, and mesh packages own Mesh.Vertices/Mesh.Indices GPU buffer shape under one resource key. The DSL can plan generic resource-backed claims over those declarations. The next blocker is no longer resolver ownership; it is selected render lowerings that consume camera/feature textures, mesh/page/volume resources as geometry, height/SDF/material pages, or density/extinction/SDF3D domains. Mesh layout authority is split by source: imported/user meshes use the standard PositionNormalUvColor layout, and generated meshes can be PipelinePrivate so each lowering owns the bytes it emits and consumes. TubeField is the first concrete generated-mesh consumer: its compute pass emits private vertex/index/indirect buffers and render binds them as D3D12PipelinePrivateGeneratedMesh before applying source/ramp/material state. The DrawIndexed indirect command signature has been lifted to the generated-mesh lane instead of being TubeField-owned. TubeField expansion now requires a planned TubeField backend packet for the lowering's claim, and validation rejects TubeSpline metadata whose claim/resource authority is split. Mimir's typed surface-intent lowering now emits the matching TubeSpline lowering for audio spectrum/waveform Tube claims. Mimir's active proof path also no longer uses the direct AquariumAcousticFieldFrame builder: sync states lower into FieldEvidence calibration constraints. Fensalir now selects audio-path Phase and Confidence claims as DebugOverlay backend packets, so calibration timing/path evidence can be inspected through the same FieldEvidence authority while true acoustic source candidates and confidence volumes remain later fusion work. The first synthetic acoustic source candidate proof now exists: Mimir lowers an SRP/PHAT-style localized source with calibration/source identity and a world-space confidence envelope, and Fensalir plans it as a FieldEvidence DebugOverlay packet. Live room geometry must still come from an explicit measured coordinate frame, not inferred from the recent two-distance monitor notes. Phase 5's synthetic marker proof now exists too: Mimir lowers a deterministic multi-camera marker candidate with calibration/marker identity and world-space support, and Fensalir plans it as DebugOverlay evidence while ambiguous raw camera features still defer. LED strips now have a typed calibration-evidence socket instead of being folded into fake depth. MimirLedSplineFieldCandidate carries ordered per-camera bright-curve samples in that sensor's image plane and local clipspace/frustum, whether the LEDs were temporally coded, and whether the sample indices are stable. BuildLedSplineCandidateFrame lowers that shared curve as deterministic camera-sensor Feature evidence; Fensalir plans it as a DebugOverlay packet through the same FieldEvidence authority. Addressable or blink-coded strips can provide exact cross-camera LED identity. Plain identical white LEDs still provide a strong spline/epipolar constraint, but their point correspondence is ambiguous under occlusion, saturation, repeated spacing, and motion blur until temporal continuity, Leap/body anchors, or the residual solver disambiguates it. MimirLedSplineCurveSolver is the first per-sensor curve owner: it orders bright detections and computes image/clipspace curve samples. MimirCameraRigCalibrationSolver is the first higher-level frustum fit owner: given stable LED indices and a scene-space LED curve anchor, it minimizes ray-to-curve distance and emits bounded camera translation updates. Individual cameras do not write calibration state. Rotation, focal length, and distortion solving are still future cuts, not hidden behavior. Exposure/gain sweeps are scored by the recovered spline, not raw brightness: MimirLedSplineQualityScorer combines detected LED count, curve coverage, spacing coherence, smoothness, exposure fitness, and saturation penalty, and MimirLedSplineSweepSelector picks the best calibration-usable setting. Once MimirLedSplineFrameAnalyzer connects physical frames to that score by extracting bright luma components, solving the sensor-local curve, and rejecting clipped blobs as unusable calibration evidence even when they are easy to detect. Mimir.BufferSmoke --led-spline-live-score is the current live sweep surface: KS/UVC cameras get manual exposure/gain writes before each scoring window, stale frames are drained, luma is extracted from the actual live frame format, and the best spline setting is reported per source. On 2026-05-31 with --expected-leds 38 --minimum-luma 0.55, both Kiyo cameras selected exposure -9, gain 8 (kiyo-pro-rgb score 0.666; kiyo-basic-rgb score 0.650). LeapUVC rejected generic KS exposure/gain writes and only found two LED components; PS3 Eye feeds are still fixed-control until the WinUSB wrapper owns gain/exposure. PS3 Eyes now also have a sparse tracking bootstrap: MimirSparseFeatureTracker detects grid-suppressed Bayer/luma corner features, links them frame-to-frame, and emits MimirFeatureTrackCameraObservation records with sensor-local image/clipspace position, velocity, age, and confidence. MimirFeatureTrackFieldCandidate lowers those observations as camera Feature claims through Fensalir field evidence. A one-second live pass at 320x240@187 with sensitive defaults returned 160 live tracks from each Eye: 160 stable tracks from ps3-eye-0 and 156 stable tracks from ps3-eye-1. This is a CPU diagnostic owner; the hot production path remains Fensalir D3D12 feature extraction. A full 2026-05-31 Fensalir headless run using the all-sensor profile started all five video sources, declared eight field resources, resolved six Texture2D resources, dispatched one packed-Leap stereo-depth kernel, generated one point-cloud/surface stream, reported 19,200 visible reservoir splats, and captured artifacts/runtime/mimir-perfect-machine-all-sensors-headless.png. The follow-up GPU feature-extraction proof planned 12 packets with zero deferred requests, dispatched sensor fusion over three sampleable camera textures, generated 49,152 sparse gaussians at about 0.059 ms/frame sensor-fusion GPU time, and captured artifacts/runtime/mimir-perfect-machine-gpu-feature-extraction-headless.png. The YUY2 decode proof then dispatched all five camera textures with zero unsupported field textures, generated 81,920 sparse gaussians at about 0.08 ms/frame sensor-fusion GPU time, and captured artifacts/runtime/mimir-perfect-machine-yuy2-gpu-feature-extraction-headless.png. Once the frustum fit is coherent, detected surface candidates can be sampled across every synchronized view before Fensalir resolves them into 4D Gaussian/surface splat claims.

The current teardown/migration map is docs/fensalir-rendering-rebuild-migration.md, paired with Fensalir's docs/rendering-teardown-rebuild-protocol.md. The intended cut is explicit: Mimir publishes typed physical observations, calibration constraints, and surface intent; Fensalir owns field domains, field claims, candidate selection, track/reservoir state, selected lowerings, temporal guide lanes, and presentation.

The reservoir can resolve pixel-level claims without requiring pixel-sized contents. Claim support belongs to the represented domain. A smooth flat surface can be a few huge surface claims; a heightfield terrain belongs in a quadtree of brush-painted surface tiles, subdivided only where projected footprint, curvature, material/brush detail, silhouette risk, or temporal uncertainty make larger claims dishonest. Fensalir's SDF probe/lowering stage should emit surface splats at that detail-adaptive density, not one splat per pixel by default.

The live debug spectrum view is now field-evidence owned. Mimir no longer submits direct AquariumSplineFrame trails for the spectrum dashboard and does not submit AquariumBufferFieldFrame / fractal ReservoirSplats for it either. Mimir declares the rolling resource, publishes a Tube claim plus AquariumFieldTubeSplineLowering, and Fensalir owns planning, generated mesh expansion, and TubeField material rendering. The spectrum resource is not just a handle: Mimir uploads the current spectral amplitudes as row-major Float32 data into a Fensalir-owned GPU structured buffer before TubeField compute reads it. TubeField writes stable field ids, real tube normals, coverage/confidence, and domain-validity guide data into the same scene metadata/control/reservoir guide targets consumed by reservoir resolve for spatiotemporal reconstruction. Fensalir's shared reservoir history update now runs as a compute pass over four structured rows per pixel and emits the resolved HDR field texture for bloom/presentation, so the presentation shader is no longer a hidden history owner. TubeField now feeds the shared reservoir from GPU-resident rolling-buffer column packets instead of generated segment packets. Fensalir emits one column packet per logical spectrum history/source column, bins those columns into screen tiles, and evaluates Catmull-Rom tube SDF/material samples directly from the source buffer during the ReSTIR passes. Generated mesh draw args are zeroed for the live path and remain only a diagnostic reference. Mimir.BufferSmoke --mimir-spectrum-upload-smoke verifies this through the actual MimirRuntime frame path and confirms the legacy direct spline and buffer-field dashboard inputs are empty. The same path declares the local blackbody ramp as a Texture2D field resource and binds the TubeField material by resource key. Runtime spectrum columns now represent (history age, source lane) pairs rather than only the latest spectra; Mimir emits one TubeField claim/lowering per source, each striding through the shared resource to render its own age trail at z = age * 0.1. The resource advertises fixed history and source-lane capacities, so content updates and source topology changes do not resize the GPU buffer while the rolling trail fills. MIMIR_SPECTRUM_SOURCE_LANES sets the fixed lane budget; surplus sources are truncated and reported in the runtime UI. Physical history slots are now addressed as a ring with RollingOffset, so logical age no longer requires moving every column before shader sampling. Mimir emits one Float32 resource upload for the newest spectrum ring slot with an explicit element offset instead of uploading the full fixed-capacity backing buffer every frame. Fensalir owns rolling-slot validity and clamps TubeField dispatch so invalid older slots are not sampled after renderer allocation, reset, or partial update. MIMIR_SPECTRUM_TUBE_SUBDIVISIONS is the runtime cost lever for lowering Catmull-Rom subdivision count when Fensalir reports TubeField truncation.

Known Risks

  • Windows device names vary by driver and localization.
  • Some FFmpeg builds omit SRT or NVENC.
  • Separate bridge endpoints can drift.
  • OBS SRT reconnection behavior can be fussy.
  • Direct driver work must prove sustained cadence before it becomes timing authority.
  • PS3 Eye audio endpoints are enumeration/runtime-fragile. A later replug made both mic buffers emit 480-frame WASAPI blocks again while both PS3 Eye camera buffers were live.