PROJECT 03 / NATIVE SOFTWARE
A creative application is only as reliable
as the system underneath.
FluxCut is an experimental desktop media-editor project. Its architecture explores a Rust core, a Tauri desktop shell, explicit command and state handling, a wgpu rendering direction, and Wasmtime as a possible boundary for future extensions. These are design and implementation directions—not a claim that every subsystem is production-ready.
A media editor coordinates user interaction, project state, timeline operations, media decoding, preview, rendering, and export. These parts must agree about timing, resource ownership, and what the project currently represents.
When those concerns are tightly coupled, a small edit can have distant effects: the undo stack may diverge, the preview may show stale state, or a media resource may outlive the operation that uses it. Users experience the whole editor as one system, regardless of where a bug originated.
FluxCut explores explicit command handling and clearer subsystem contracts so state changes can be validated, tested, undone, and communicated to the rendering path. It is a work in progress and should not be confused with a production alternative to established commercial editors.
One authoritative project state. Explicit commands. Defined resource ownership. A rendering path with observable inputs and outputs.
This diagram describes the intended separation of responsibilities; not every subsystem is complete or production-ready.
Rust provides explicit ownership and strong types that are useful when many resources and state transitions meet. The trade-off is engineering complexity: asynchronous pipelines, media resource lifetimes, and cross-platform integration require deliberate design and debugging. Language choice alone does not make an editor fast or robust.
Tauri is the chosen desktop shell direction, allowing a web-based UI to communicate with native capabilities. The boundary between UI and core needs a clear command protocol, explicit error handling, and limits on long-running work so that the interface does not become coupled to internal implementation details.
wgpu is part of the project's rendering direction. A sustainable rendering system needs a defined frame graph, resource lifetime management, predictable synchronization, and performance instrumentation. The target is a maintainable path from timeline state to rendered preview—not simply a GPU label on the stack.
Wasmtime is an exploration point for safely running future extensions or user-defined processing logic in a constrained environment. Sandboxing still needs a carefully designed permission model, resource limits, versioning, and a clear host API; it is not a blanket guarantee of safety.
A compelling interface is only a first impression. A useful editor must preserve frame-accurate timing, keep audio and video synchronized, support predictable undo/redo, recover projects, report missing media clearly, and produce exports that match the timeline.
The project therefore needs tests around state transitions and media timing as much as it needs a compelling interface. Each new feature should have a small, explicit definition of correctness.
Keep edits explicit, define preconditions and error states, and test the core timeline state independently of the UI.
Define responsibilities for import, decoding, preview, and export; instrument the pipeline before making performance claims.
Before running extensions, define the host API, permissions, time and memory limits, isolation model, and failure recovery. A sandbox is not a substitute for a threat model.
EXPERIMENTAL SOFTWARE
FluxCut remains experimental. Progress should be demonstrated through reliable edit operations, coherent state transitions, media handling, and workflows that can be tested—not by architecture diagrams alone.