zpwr-clip-engine — Engineering Report

Shared component, two halves. A canvas-2D arranger/sequencer frontend (webui/) and the pattern→events→step/transport/MIDI scheduler (engine/, a header-only C++17 C ABI). Both were extracted verbatim from zpwr-daw so every host shares one implementation.

Architecture

zpwr-clip-engine is consumed two ways from one source. The frontend (webui/) is mounted by hosts through initClipSeq({ nf, getCAT }): one canvas grid renders swappable domains (arranger, notes/piano-roll, launcher/session, automation lanes) plus the clip palette. The engine (engine/) is the scheduler as a pure-C++17, header-only C ABI (zpc_clip_*) — ClipEngine + MidiFile, no JUCE, no external deps — built both as a static lib the JUCE daw links natively and as a dylib/.so the Tauri apps load through a Rust FFI wrapper. The nf bridge is what differs per host; the grid and the scheduler do not.

Module map

area	responsibility
webui/grid	the canvas grid — model, interactions, cursors, sequencer, project state, domain entry (`index.js`, `grid-core.js`, `grid-model.js`, `grid-interactions.js`, `sequencer.js`, `project.js`)
webui/clip	the clip layer — clip grid, clip bank/palette, sequencer view, and the non-audio basic backend for preview (`clip.js`, `clip-grid.js`, `clip-bank.js`, `clip-seq.js`, `clip-basic-backend.js`)
webui/lib	shared frontend helpers used across the clip and grid layers
engine/	the C++17 header-only scheduler exposed as the `zpc_clip_*` C ABI — `ClipEngine` (pattern → events → step/transport) and `MidiFile` (MIDI export)
bindings/	the build glue producing the static lib (native daw link) and the dylib/.so (Tauri Rust-FFI load) from the one engine source

Consumers

zpwr-daw (JUCE / C++) — links libzpwr_clip_engine_static.a natively and drives the grid via native nf functions, adding its own audio voices / per-track instruments for real sound.
Tauri apps (Audio-Haxor, traderview, ztranslator) — load libzpwr_clip_engine.dylib/.so through a Rust FFI wrapper and bridge nf → the C ABI.
One source of truth — the grid and scheduler are never re-implemented per app; only the nf backend bridge and supplied content differ.

Build

The engine builds two artifacts from one C++17 header-only source via bindings/: libzpwr_clip_engine_static.a for native linking and libzpwr_clip_engine.dylib/.so for FFI loading. Because it is header-only with no JUCE or external dependencies, the same engine embeds in native and Tauri hosts without divergence.