Backline: A Native DAW and Video Editor in Sync

Why this exists

Musicians who score to picture work across two tools that were never meant to talk to each other. The audio lives in a DAW, the video lives in an editor, and keeping them aligned is manual work that has to be redone every time either side changes.

Backline is one application where the timeline is shared. You cut picture and you cut music against the same clock.

The hard constraint: the audio thread

Real-time audio has a rule that shapes every other decision. The audio callback runs on a high-priority thread with a hard deadline, and if you miss it the user hears a click. Not a slow frame, an audible defect.

That means no allocation on the audio path, no locks, no file access, and no anything that can block for an unbounded time. Communication with the rest of the app happens through lock-free structures, and state the audio thread needs is prepared in advance by threads that are allowed to be slow.

Most application code is written as though waiting is free. On the audio thread it is the one thing you cannot do, and that inverts a lot of ordinary instincts.

Keeping picture locked to sound

Video is slaved to the audio clock rather than the other way around, because audio is the unforgiving one. A dropped video frame is a visual hiccup. A gap in audio is a click that ruins a take.

So the transport derives from where the audio engine actually is, and the video pipeline chases it. That ordering is the difference between a tool a composer trusts and one they stop using after a week.

A timeline that survives leaving the app

The edit model is backed by OTIO, an interchange format for timelines, so a project can round trip to other tools without being flattened into a rendered file.

This is a bet about how people actually work. Nobody uses one application for an entire project. A tool that cannot hand its work to the next tool becomes a dead end, no matter how good it is in isolation.

Why native, and why C++

Cross-platform frameworks are the right answer for most products and the wrong answer here. Real-time audio needs predictable latency and direct access to the platform's audio stack, and layers of abstraction between you and the hardware are exactly what you cannot afford.

So it is C++ and JUCE for the audio side, with the platform's own frameworks for video. Harder to write and the only way to hit the deadline reliably.

The honest status

This is a build in progress, not a shipped product, and the architecture and decision records are public in the repo. I am including it because the reasoning is the interesting part: it is the clearest example I have of designing around a constraint that cannot be negotiated with.