// ZPWR-DAW — ENGINEERING REPORT

>_EXECUTIVE SUMMARY

zpwr-daw is a standalone DAW arranger engine (formerly zpwr-clip-engine) shared across the MenkeTechnologies audio stack. It is a reusable component with two halves: a host-agnostic web UI (a generalized FL-Studio-style canvas grid — one renderer + one interaction model + one value model, bound to a domain) and a C++ engine (pattern model, swung step clock, event queue) reached directly from C++ and over a C ABI (FFI) from Rust. The frontend never knows whether it runs inside JUCE or Tauri — it calls an injected nf transport object, with adapters for the JUCE WebBrowserComponent native-fn bridge and Tauri invoke. Playback runs on a native audio-thread step clock when the host wires it (minimise-proof) and falls back to a JS timer otherwise. It is a two-view DAW: an Arrangement timeline (tracks, clips, sections, tempo/meter maps, markers, breakpoint automation) and a Session clip launcher (scenes, follow actions), plus MIDI/JSON export and an in-progress JUCE audio-clip layer. Because that timeline moves notes and audio along one shared clock, adding a video track type made it the first DAW that is also a full video editor — the whole Adobe Premiere Pro feature surface has been built out against the same arranger until 0 features remain gap (see the Adobe Premiere Pro Port Report). All line counts below are from tokei: the C/C++ / Rust / CMake / Python engine, C ABI, JUCE app and FFI bindings in the repo tree (excluding every vendored libs/ submodule and all build output), plus the JavaScript arranger/grid engine in libs/zpwr-clip-engine; the arranger feature count is read from docs/arranger_port_report.html; test counts are grepped from the test trees.

#CODE VOLUME — tokei

Raw tokei output for the engine sources: the C/C++ / Rust / CMake / Python in the repo tree (every vendored libs/ submodule and all build output excluded) plus the JavaScript arranger engine in libs/zpwr-clip-engine. Three real languages carry the engine: C/C++ for the pure engine + C ABI + JUCE glue + note-stream module pack, JavaScript for the grid engine + domains + transport bridges + sequencer + exporters, and Rust for the FFI bindings.

Figures are the tokei per-language rows; the TOTAL row sums them. The HTML row's nested CSS/JS sub-rows (4 CSS + 4 JS embedded fragments, 119 embedded JS lines counted separately from the standalone JavaScript headline above) and the Rust/Markdown nested-language sub-rows are part of tokei's breakdown, not separate files.

@ARCHITECTURE

One renderer, one interaction model, N domain bindings, two transport bridges. The frontend calls an injected nf; the bridge decides JUCE-vs-Tauri. The pure C++ ClipEngine sits below both: linked directly by the JUCE plugins, reached over the C ABI by the Rust/Tauri hosts. The same engine, driven from a JUCE processBlock audio callback or a Rust-side timer.

  webui/grid/  (one renderer + one interaction model + one value model)
       │
       ▼
  ┌──────────────┐   bound to a domain   ┌──────────────────────────────────┐
  │  grid engine │──────────────────────▶│ domains/  notes · arranger ·      │
  │  render loop │                       │           automation · triggers · │
  │  hit-test    │                       │           autolanes · launcher    │
  │  all gestures│                       └──────────────────────────────────┘
  │  popover     │
  └──────┬───────┘
         │  nf(name)(...args)
         ▼
  ┌──────────────┐        ┌──────────────┐
  │ juce-bridge  │        │ tauri-bridge │      transport/  (host-agnostic)
  │ native fns   │        │ invoke(...)  │
  └──────┬───────┘        └──────┬───────┘
         │  clipSeq* JSON         │  clip_seq_* JSON  (identical shape)
         ▼                        ▼
  ┌─────────────────┐     ┌──────────────────────┐
  │ ClipSeq.h       │     │ capi/clip_engine.h    │   C ABI (extern "C")
  │ JUCE native-fn  │     │ src/capi/*.cpp        │   compiled by cc for -sys
  │ contract        │     │ bindings/rust/        │   safe Rust wrapper
  └────────┬────────┘     └──────────┬───────────┘
           │                         │
           └───────────┬─────────────┘
                       ▼
            ┌────────────────────────┐
            │  ClipEngine.h (pure)   │   pattern model + swung step clock
            │  no WebBrowserComponent │   + event queue; timing ported
            │  JUCE-free core path   │   verbatim from clip.js fallback
            └───────────┬────────────┘
                        │
            ┌───────────┴────────────┐
            ▼                        ▼
   ┌────────────────┐      ┌──────────────────────┐
   │ MidiFile.h     │      │ midi/ note-stream pack │
   │ Type-0 SMF     │      │ Chord/Arp/Scale/       │
   │ (byte-id w/ JS)│      │ Euclidean/automata     │
   └────────────────┘      └──────────────────────┘

&GRID ENGINE & DOMAINS

A domain supplies everything that differs (lanes, time-axis cells, value type, which gestures apply, serialize shape); the grid engine supplies everything shared (render loop, hit-test, all gestures, popover bulk-edit, persistence). The single most important merge detail: value.type selects the edit-drag axis — 'length' → horizontal right-edge note resize, 'unit' → vertical top-band value height, 'bool' → click toggle. There are 6 domain files under webui/grid/domains/.

// INTERACTION PARITY CHECKLIST (REGRESSION CONTRACT)

The grid engine must preserve every gesture from the ALS timeline it was lifted from. The full gesture set, domain-independent, survives the port:

!C++ ENGINE · C ABI · RUST BINDINGS

The pure C++ ClipEngine (no WebBrowserComponent dependency) advances a swung step clock and queues note on/off events. Timing/length semantics are ported verbatim from the clip.js fallback sequencer, so the C++ core, the C ABI, and the JS clock all advance identically. The C ABI exposes it to Rust so Audio-Haxor / ztranslator drive the same engine the JUCE plugins drive; the -sys crate compiles the JUCE-free clip_engine.cpp directly with cc — no CMake or JUCE on the Rust path.

%ARRANGEMENT & SESSION · EXPORT

Two views over the same engine. The Arrangement view (arranger domain) is a timeline of tracks, clips, sections, tempo/meter maps, markers and breakpoint automation; double-click a clip drills into its notes. The Session view (launcher domain) is a clip launcher with scenes and follow actions. Any pattern renders to a Type-0 Standard MIDI File — the universal DAW interchange format — so output drops straight into Ableton, FL, Logic, Reaper. The C++ (MidiFile.h) and JS (export/midi.js) writers emit byte-identical files, verified by round-trip parsing in the test suites.

^ARRANGER PORT COVERAGE

The detailed per-feature coverage audit lives in the DAW Arranger Port Report: every arranger feature across Ableton Live, FL Studio, Logic, Cubase/Studio One, Bitwig and Pro Tools, mapped to where it lives in this engine. It is a citation-backed coverage map — every PORTED row names the exact file:line; there is no ‘100% / 0 gaps’ claim. The audio-clip features are a phased JUCE build (Phase 1 import + waveform done in the webui and verified; playback + DSP, phases 2–7, stay GAP until built in a compiled plugin and heard).

Counts read directly from docs/arranger_port_report.html (“63 in-scope features · 57 ported · 0 partial · 6 gap”). Every MIDI-arranger feature is ported; the 6 gaps are the unverifiable audio-clip playback/DSP phases that need a compiled plugin and a human listening.

~VIDEO EDITOR · PREMIERE PORT COVERAGE

A video clip is just another thing the arranger carries, so dropping a video track type onto the shared timeline turned the DAW into a non-linear video editor on the same canvas — making zpwr-daw the first DAW that is also a full video editor. The whole Adobe Premiere Pro surface was then built out against it, area by area, until 0 features remain gap. The per-feature audit is the Adobe Premiere Pro Port Report: every PORTED row names the exact file:line in libs/zpwr-clip-engine/webui where it lives — the citation is the proof, not a self-assigned score. The 2 PARTIAL rows are shipped-with-a-limitation, not missing (native sample-accurate audio DSP wants a compiled plugin; Productions multi-user wants a shared-storage sync transport).

Counts read directly from docs/premiere_port_report.html (“202 Premiere features · 200 ported · 2 partial · 0 gap”), generated by scripts/gen_premiere_port_report.py. Coverage spans media/project, timeline editing, source-clip trim, monitors, motion/compositing/keying, effects & transitions, Lumetri color, audio, titles/Essential Graphics, multicam and export/Media Encoder.

*TESTS

Three real test surfaces, one per layer of the engine: headless JS for the grid model / domains / layout-hit math / sequencer / exporters, Rust integration tests that drive the engine through the safe FFI wrapper, and a headless C++ harness that pins the note-stream module pack. Every count below is grepped from the test trees.

JS: grep -cE "^\s*(test|it)\(" over webui/grid/tests/*.mjs = 66. Rust: grep -c "#[test]" over bindings/ = 7. C++: check( call sites in tests/MidiModulesTest.cpp = 8. The exporters are additionally cross-checked by round-trip parsing inside the JS and Rust suites.

+CONSUMERS

Five consumers across the MenkeTechnologies stack share one frontend + one engine. The three JUCE plugins drive it directly via the native-fn bridge; the two Rust/Tauri hosts drive it over the C ABI through the safe wrapper.

?KEY DESIGN DECISIONS

Why zpwr-daw looks the way it does. Each call-out is a decision the implementation could have gone either way on.