Open DJ 1.0 alpha

Open DJ is a local-first DJ app with a rekordbox-familiar four-deck screen. It reads your rekordbox library or a plain music folder, and plays prepared stems and lyrics inside the deck. Most deck and mixer controls are typed commands, reachable over HTTP, the opendj command line and opendj mcp, so a script or an AI agent can drive them the way you do. It is Apache-2.0 licensed, and the source is planned to open on Mon 5 Oct 2026 as a public mirror (Contributing).

It is not the first DJ app you can read the source of. Mixxx is the established open-source DJ app, and if you want a mature, cross-platform, free DJ app today, use Mixxx. Open DJ is a younger project that makes different bets, described below.

Not the OpenDJ LDAP directory server. Different project, same unlucky name.

I DJ as a hobby, and for years the thing that annoyed me most was not the mixing, it was the library. My cues, grids, ratings and play orders lived inside one vendor's database, in a format I could not easily get back out. Open DJ started in April as a set of tools to get my own library out and keep it honest, and only later grew decks.

• A four-deck screen that fits a small window. Four decks, the mixer and the library stay usable in a 1280 by 720 window, with a 2-deck and 4-deck toggle on Cmd+2 and Cmd+4.
• The deck basics where your hands expect them. Hot cues A to H jump, beat loops move with beat jump, quantize, Beat Sync with automatic master handoff, master tempo. Empty pads show suggested cue points, marked as proposals until you keep them (deck).
• Your rekordbox library, or a folder. First-run import covers rekordbox and plain folders. Folder imports are labeled unanalyzed until Open DJ runs its own beatgrid, key (with a confidence value) and loudness analysis. Adapters for djay Pro, Serato and Traktor libraries exist in the code and run from the command line today; they are not in the app's import screen yet.
• It will not write to your rekordbox library by default. Every code path that can write to the live rekordbox database, a Pioneer share or a USB export is listed in one inventory and off by default. The installed Mac app clears the write switch before its engine starts, so it will not write to your rekordbox library, a Pioneer share or a USB export; its one library write is a djay playlist write-back, which runs only after you confirm it and backs up the playlist first. From a source checkout, writes are off by default; the one exception is undo of an earlier write you allowed.
• A library that knows what will actually play. Open DJ classifies every row as present on this machine, broken here, on another machine, waiting for a drive, streaming, or with no path, and grays out rows whose file is gone; the health light that will sum this up in the library view is still open (HEALTH-01). If a scan finds zero files where it found thousands before, it fails loudly and marks nothing missing (library).
• Stems you have prepared, on every deck. Press STEM and a channel's EQ dials become stem dials; mute and solo sit on every strip. Making stems from the installed app on a clean Mac is still pending (below).
• Lyrics under the playhead. The app shows line lyrics, fetched from free sources and cached locally, and a word-level lyric lane on the waveform when word timings exist (LYR-03). Library search finds a track by a lyric phrase.
• Crash rescue. Reopen within 10 minutes of a crash and the decks resume where the beat would now be, with one Undo. Within 24 hours it restores layout, tracks, cues and faders without playing.
• Prep and Gig. Switch from Prep to Gig and background work is capped for a live set; library sync will not run while any deck is playing unless you force it.
• Typed commands, and an agent interface with rails. Most deck and mixer actions dispatch as typed commands (fader, crossfader, beat_sync, stem_mute and more) through one bus that the UI, keyboard, MIDI and the opendj command line share. The Mac app's payload includes the opendj command line and an opendj mcp server (AGENT-11), so any MCP client can read deck state and send commands. The rails live in the server: master output is muted before an agent can press play, rekordbox writes are blocked, and destructive library calls are refused (agents).

Agent control of DJ software is not new in itself: community MCP bridges exist for Mixxx (mixxx-mcp) and VirtualDJ (VirtualDJ-MCP-Server), seen Fri 2 Oct 2026 and not tested by this project. The difference here is that the interface is first-party and ships in the app.

• macOS on Apple silicon only. No Windows or Linux build.
• Controllers and MIDI are not supported in the Mac app in this alpha. The macOS window uses WebKit, which has no WebMIDI. Controllers work in Chrome or Edge only when you run Open DJ from a source checkout. There is a DDJ-FLX4 map with 42 MIDI messages confirmed on a real unit (Fri 18 Sep 2026, from a sweep of about half the controller), older maps for the DDJ-400, DDJ-FLX10 and Reloop Mixtour, and the project README records the rig being played live on a DDJ-400 (hardware). Other controllers need a map; there is a learn log that shows what each control sends, not a click-to-bind MIDI learn.
• Stems from the installed app are not yet proven. Stems play from a stem cache. The code to make them from the installed app is in, but STEM-39 stays open until a signed build separates a track on a clean Mac, so today they come from a source checkout.
• Word timings need a source checkout. Making them runs the lyrics pipeline (LYR-02); the app does not make them. Line lyrics coverage depends on what the free sources hold.
• Some top bar controls are not typed commands yet, such as the drawer and overlay open state. Master volume and master mute are typed commands on the dispatcher.
• Hot cue save and clear are built but not yet verified on a real library.
• Serato (libraries from before Serato 4.0), Traktor and djay are read by command-line tools from a source checkout, not by the app's import screen. Whether folder import reads tags in the packaged app is not yet verified (PARITY-15 is open).
• No analysis accuracy figure is published yet. Analysis was benchmarked against rekordbox and Mixed In Key (PARITY-01, NATIVE-04, BEATMAP-01), but the downbeat accuracy target moved to a later version.
• Bluetooth headphone cue calibration is partial; real Bluetooth coverage is pending (CUEOUT-12).
• Signing. Whether the launch build is signed and notarized is stated next to the build itself, on the Download page.
• No public issue tracker at launch. The private security route opens with the public mirror (Security), and hello@open-dj.com works once its forwarding is verified.

It is an alpha in the plain sense: features and stored formats can change between releases.

April: a library layer, in two days

The first commit is Thu 16 Apr 2026. By the end of Fri 17 Apr there were 447 commits and a tagged release of a library toolchain: rekordbox missing-file repair, playlist and cue sync with djay, smart playlists and the first version of the open-dj library format, with 51 of 53 requirements shipped and 2,251 tests passing. It was not smooth: the first release candidate could not build a package and the second failed at runtime on its first import (changelog). That layer is still a live dependency of the DJ app.

July to October: the performance rig

The decks, mixer and performance view started with a scaffold commit, 0d0a7811be, on Tue 21 Jul 2026. Since Wed 1 Jul there have been 10,554 commits and 2,097 merged pull requests (merge commits plus squash merges), and 88.6% of those commits landed in August and September. So the honest summary is: a performance rig built in about eleven weeks, most of it in August and September, on a library layer from April. Not "from zero in two months".

The build system

Agents wrote much of the code. The repository cannot say how much, because most agent commits are made under my name. The project runs as an agent build system (the machine):

• GitHub issues are the queue; each has acceptance criteria.
• A worker claims a feature in a shared ledger before building, with a time-limited lease, so two agents rarely build the same thing.
• Agent workers on several machines build in parallel, each on its own branch and worktree.
• Each pull request head needs a review from at least one of five reviewer lanes from four vendors (OpenAI Codex, an OpenAI model run through the Codex command line, xAI Grok, Cursor and Anthropic Claude), with a failover chain when one is unavailable. These reviewers are models, not people. A review can be carried forward from an earlier head only by a written rule.
• A merge queue is the only path to main.
• Architecture decisions are written down (226 decision records), and the rule is that any change to behavior updates the requirements file in the same pull request (744 requirement items checked, 101 open).

What a person decided, each with its date, is on the How it was built page: scope, what blocks v1, the house rules the agents work under, licensing, and taste.

It was not clean either, and the records say so. From Thu 10 Sep 2026, in a period the project called ship mode, build lanes merged on their own tests without waiting for the full CI run on the pull request (decision record ADR-0042). In that period at least one blocking review finding was partly fixed and its remainder logged as debt past a merge (PR #1010, Thu 10 Sep 2026). The written rule is that a blocking finding is fixed or rebutted before merge; ship mode relaxed it, and the debt file records where. In plain terms: for a few weeks some changes went in with fewer checks, and the records list which.

Three things the process caught

Each one ends in a number someone can re-derive.

• A preview that started in 743 ms now starts in 28 ms, once you have hovered the row. The first timing said the wait was file transfer; it was taken on an overloaded machine and thrown away. Re-measured, decoding was most of the wait, so the fix warms the decode on a half-second hover. One end-to-end run, and the first preview of a session still pays the decode.
• 75 percent of my own library's paths were dead. On Tue 28 Jul 2026, 6,269 of 8,355 recorded paths pointed into a home directory that no longer exists on my Mac. rekordbox does flag missing files: it shows a dialog at startup once 50 or more are missing, and it has a Missing File Manager. What I wanted was a state on every row, present, missing or on another machine, and a count I could trust with its denominator: only 1,186 of those 8,355 rows had audio on disk at all. That is what Open DJ adds.
• Undo, proved. A relink changed 172 rows on a scratch copy of the real database; undo reverted all of them, and a cell-by-cell diff over 8,355 rows by 11 columns found zero differences apart from the update timestamp. A 5-row version of that diff is now a regression test, run wherever a real library is present.

My stated goal for the build system is that Open DJ could rebuild itself from scratch in a week: from the specs and requirements alone, in an empty repository, the fleet rebuilds the product. That is a goal, not a result. No timed rebuild has been run. When one is, I will publish the start and end commits, the wall-clock time, which requirements passed and what it failed to reproduce, and I will define "rebuilt" before the clock starts so the finish line cannot move (the goal).

• A signed and notarized build, if the launch build is unsigned.
• Controllers in the Mac app. Moving the app shell to Electron is the first v1.1 item (open PR #3867); that shell gives the page Web MIDI (ELECTRON-06). It is not in this build, and the roadmap tracks it.
• Making stems from the installed app (STEM-39).
• The second build-log entry, on why parity was only the starting line: what a mouse and screen can do that a controller layout cannot.
• Later: a timed, logged run of the rebuild goal above.

Back up your library first. Where to send what breaks is under What does not work yet, last item.