Virtual club and LAN demo
Scope of this page: the platform's earlier two-deck session renderer and LINK replay. The primary club runtime now uses one shared mixer plus four independent CDJs, with five-container deployment instructions. Its live controls, audio and MIDI interfaces are separate from this recorded-session demo. Do not infer that the Next.js B2B page already controls the new runtime.
The current executable slice is two virtual audio decks sharing one mixer, with two to four actors rotating control. A selected transition now compiles to actual leased controls: load, cue, key-locked tempo, play, fader ramps, complementary bass exchange, optional high-pass filter-out, and stop. The rendered audio reads this control state. The orchestrator grants a temporary transition lease over both channels to the incoming actor; this is cooperative B2B, not adversarial shared control.
Candidates expose 16/32-beat blends and 16/32-beat filter-outs. The LLM selects a feasible option. The deterministic compiler schedules it. Arbitrary live jog, loops, hot cues, sync/master handshakes, crossfader, headphone cue bus, manual browser audio control and live sound-card output are not yet implemented. This is not a hardware-accurate DJM filter model.
Sessions now include commands.json and booth.jsonl alongside decisions, events and WAV. The UI loads recorded booth controls with the mix and follows the audio playback position at 5 Hz. Offline rendering and protocol replay are separate from live playback: API planning/render progress is not a claim that a club is currently playing.
Source ownership
aidj-club-emulator is an independent Prochain repository with an unchanged snapshot of OllieCross/CDJ_DJM_Emulator at b19b7ca5834f16d4605417c8b413ea8ec8832d4b and an actively maintained prochain-club-protocol crate. Upstream's Rust workspace declares MIT OR Apache-2.0. Its authors retain their original copyrights; Prochain owns repository administration and its modifications. See the repository's provenance record.
The platform includes a synchronized source copy so private cross-repository Git authentication is not required to build. The active codec is cross-platform and independent of audio, feth and Tauri. The original full application is retained as source, not linked: its checkout lacks the patched vendored rekordcrate dependency it expects.
The protocol audit corrected beat/header offsets and mixer BPM/pitch offsets against DJ Link analysis. Upstream round-trip tests alone had not caught these mismatches. These are documentation-based fixes, not real capture certification.
LAN proof point
Target: aidj on a Linux Docker/Kubernetes node, Windows running rekordbox EXPORT mode and the aidj web UI. Both must be on the same broadcast domain for the current discovery approach. A Kubernetes ClusterIP/Ingress cannot substitute for PRO DJ LINK broadcast. The deployment template uses host networking, an explicit LAN node, persistent session storage and injected secrets. A NATed Docker Desktop/WSL node is not assumed to work.
Reserve and assign three local IPs for player 1, player 2 and mixer before launching the bridge. No automatic host changes or collision negotiation are performed. Synthetic MAC announcements are a limitation of the current single-NIC replay adapter.
booth-cli link-capture SESSION_ID
booth-cli link-replay SESSION_ID PLAYER1_IP PLAYER2_IP MIXER_IP LAN_BROADCAST_IP
The capture is generated from recorded controls using documentation IPs. LAN replay emits at 1x with basic metadata service; it neither streams audio into rekordbox nor performs LINK EXPORT track loading. UI audio and LAN replay do not yet share an automatic synchronized start. See the platform deploy/README.md for ports and test steps.
| Capability | Current evidence |
|---|---|
| Frame-scheduled control transitions | Automated state/audio/replay tests |
| Discovery, beat, status projection | Codec tests, generated PCAP and UDP delivery from three local IPs |
| Basic title/artist/key/BPM/duration service | TCP discovery and metadata-client tests on loopback |
| XDJ-AZ buttons, tempo, EQ/fader/filter input | Tests against MIDI E1 message assignments |
| Real rekordbox LINK discovery and track display | Pending Windows/LAN test |
| Physical CDJ/DJM/XDJ validation | Pending |
| PDB/ANLZ ingestion through upstream emulator | Not ported |
| Native USB databases / LINK EXPORT loading | Not implemented |
XDJ-AZ direction matters
The official MIDI E1 table distinguishes controller input from computer feedback. The adapter decodes controller messages and can encode a play LED response. It does not claim that those output bytes remotely start the XDJ-AZ standalone engine. EQ/filter values remain raw because the table does not specify the complete DSP response curve; the channel fader direction follows the table's upper=0/lower=127 assignment.
Shared mixer and B2B channel controls
The live emulator has four independent channel strips feeding one shared master: trim → three-band EQ → filter → channel fader → optional crossfader gain → master. Each channel can be assigned to A, B or THRU. THRU is the default and bypasses the single shared crossfader. A and B name crossfader sides, not DJs. For example CH1=A, CH2=B, CH3/CH4=THRU lets one DJ crossfade channels 1/2 while 3/4 are unaffected. There are no per-DJ crossfaders or hidden DJ summing buses. The live UI exposes these assignments next to each channel strip.
Selectable crossfader curves
The shared curve selector exposes four application-defined gain laws. They are
not claimed to reproduce a measured DJM-A9 hardware curve. With
t = (position + 1) / 2, side A uses x = 1-t and side B uses x = t:
| Curve | Gain | Center gain per side |
|---|---|---|
| Club (default) | min(1, 2*x) | 1.0, preserving the previous behavior |
| Linear | x | 0.5 |
| Equal power | sin(pi*x/2) | approximately 0.707 |
| Cut | min(1, x/0.05) | 1.0, with a 5% travel ramp near each closed end |
THRU always has unity crossfader gain. Channel fader, trim, EQ and filter still apply. Equal-power gains have a squared sum of one; this does not guarantee constant loudness for correlated or differently mastered tracks. Curve changes apply immediately. Like other live mixer controls, the selection is in-memory and returns to Club when the engine restarts.
The emulator accepts {"action":"crossfader_curve","curve":"equal_power"}
and publishes mixer.crossfader_curve in its state. Distributed-player on-air
indicators and the audio mixer use the same gain function. The Prochain MIDI
mapping adds channel-1 CC23 for Club/Linear/Equal Power/Cut at values
0–31/32–63/64–95/96–127. CC24 on MIDI channels 1–4 assigns that mixer channel to
A/THRU/B at values 0–42/43–84/85–127. Existing CC21 crossfader and CC22 master
mappings remain in place. Raw engine/MIDI endpoints are trusted operator
interfaces, not per-user endpoints exposed by the browser.
Channel permissions
The owner assigns people or AI to seats through Booth members and DJ positions. A seated human DJ A can control decks and CH1–2; DJ B can control decks and CH3–4. This covers channel fader, trim, all three EQ bands, filter and A/B/THRU assignment. The UI labels each strip's owner and disables other strips. The command API independently checks current MongoDB membership and seat assignment on every request, so changing a seat or revoking a role takes effect without trusting cached browser permissions.
The owner can control every channel. Both seated DJs can use the shared crossfader, its curve and master gain. Listeners, outsiders and DJs without a human seat cannot write controls. An AI seat does not grant another human its channels; live autonomous scheduling and its control leases remain separate work. Beat FX and booth/headphone buses are not implemented as A9 hardware features. Offline B2B transitions already automate channel faders, EQ, filter and trim.