Chapter 1: Overview

DjMirror Pulse includes a built-in server/client architecture that lets a single master instance (the server) drive any number of secondary instances (the clients) across a local network. Every client mirrors the server's configuration in real time — style changes, brightness, effects — so you can run multiple screens or rooms from one control point without reconfiguring each machine individually.

This guide is written for AV integrators, event production companies, and venue IT staff who need to deploy DjMirror Pulse in a networked multi-screen or multi-room environment.

Supported desktop platforms: Windows and macOS. Linux is not a supported DjMirror Pulse desktop server or client platform. Android is supported as a separate mobile remote control; it does not act as a multi-screen display client. See Mobile Remote Guide.

Chapter 2: Architecture Overview

Figure 1: the desktop server sends configuration updates to each screen client; the Android mobile remote controls the server but is not a display client.

How changes propagate:

Each client reads the server's full configuration on startup, then applies every subsequent change immediately. If the WebSocket connection drops, the client automatically retries every 5 seconds — no manual intervention needed.

Chapter 3: Requirements

Network Requirements

Software Prerequisites

• DjMirror Pulse installed on every machine (server and all clients)
• Network path open between all machines (ping test recommended before show)
• Static IP address or DHCP reservation configured for the server machine

Media Availability (Visuals/ on Every Machine)

Only configuration travels over the network — media files never do. Each machine resolves playlist entries, style assets and artist media against its own local documentsPath/Visuals/ tree, so every client needs the same files the server uses, or layers render black/missing while config sync looks fine. Two supported layouts:

Rules for both: keep identical subfolder structure and filenames (playlists reference bare filenames); point every machine's documentsPath at its copy (see Config & CLI); verify by loading each style/playlist on one client before doors. Note: with a network share, video decoding streams over the LAN — prefer wired Gigabit and pre-test your heaviest loops; with local copies, disks do the work and the LAN carries config only.

Chapter 4: Setting Up The Server

The server is the machine an operator uses to control the show. All other machines follow it.

Step 1 — Launch the Server

Open a PowerShell (or Terminal) window and run:

.\DjMirrorPulse.exe --server --port 8080

Step 2 — Configure via config.json (optional)

Alternatively, set server options permanently in config.json next to the executable:

{
  "server": true,
  "port": 8080
}

The command-line flags always override config.json. A server restart is required for these settings to take effect.

Step 3 — Verify the Server Is Running

From any computer on the network, open a terminal and run:

curl.exe http://SERVER_IP:8080/config

Expected responses:

Chapter 5: Connecting Clients

Windows and macOS

On each client machine, open a terminal and run the command for its operating system:

# Windows (PowerShell)
.\DjMirrorPulse.exe --no-server --client http://192.168.1.50:8080

# macOS
./DjMirrorPulse --no-server --client http://192.168.1.50:8080

Replace 192.168.1.50 with the actual IP address of the server machine.

Persistent Configuration via config.json

To avoid typing the command every time, set the client URL in config.json:

{
  "server": false,
  "client": "http://192.168.1.50:8080"
}

An empty "client": "" value means "no client mode."

Chapter 6: Firewall Configuration

Open the following inbound TCP ports on the server machine's firewall. Client machines do not require any special firewall rules (they make outbound connections only).

Windows Firewall (PowerShell — run as Administrator)

# HTTP port
New-NetFirewallRule -DisplayName "DjMirror Pulse HTTP" `
  -Direction Inbound -Protocol TCP -LocalPort 8080 -Action Allow

# WebSocket port
New-NetFirewallRule -DisplayName "DjMirror Pulse WebSocket" `
  -Direction Inbound -Protocol TCP -LocalPort 8081 -Action Allow

macOS Firewall

If the macOS Application Firewall is enabled, allow DjMirror Pulse through it in System Settings → Privacy & Security → Firewall → Firewall Options.

Chapter 7: API Key Authentication

For venues where network security matters, you can require an API key on the server so that only authorized clients can connect.

Setting the API Key

Set the key using any one of these methods (listed in order of priority — higher items win):

1. Environment variable (highest priority):

   $env:DJMIRROR_API_TOKEN = "YOUR_SECRET_KEY"
   .\DjMirrorPulse.exe --server
   

2. config.json:

   { "apiKey": "YOUR_SECRET_KEY" }
   

3. Settings → Mobile app (API security section) in the DjMirror Pulse UI

Connecting Clients with the Key

.\DjMirrorPulse.exe --no-server --client http://192.168.1.50:8080 --client-key YOUR_SECRET_KEY

Or set it permanently in config.json on the client:

{
  "client": "http://192.168.1.50:8080",
  "clientApiKey": "YOUR_SECRET_KEY"
}

Testing Authentication

# Should return the config JSON (not UNAUTHORIZED)
curl.exe -H "X-API-Key: YOUR_SECRET_KEY" http://SERVER_IP:8080/config

# Alternative header format also accepted
curl.exe -H "Authorization: Bearer YOUR_SECRET_KEY" http://SERVER_IP:8080/config

Chapter 8: Verifying Synchronization

Use this checklist after connecting all clients to confirm the setup is working correctly.

Synchronization Checklist

Reading the Client Log

To see exactly what a client is doing, start it with --console and pipe the output:

.\DjMirrorPulse.exe --no-server --console --client http://192.168.1.50:8080 2>&1 | Tee-Object client.log

Key log lines to look for:

$env:QT_LOGGING_TO_CONSOLE = "1"
$env:QT_FORCE_STDERR_LOGGING = "1"

Chapter 9: Multi-Room & Large Venue Scenarios

Scenario A — Single Room, Multiple Screens

Run one server and connect one client per screen. All screens show the same content, synchronized in real time.

[Operator Laptop — Server]
       │
       ├── [Stage Screen L — Client]
       ├── [Stage Screen C — Client]
       └── [Stage Screen R — Client]

Scenario B — Multi-Room Venue

Each room has its own display machine (client). All rooms follow the same server.

[Lighting Booth — Server :8080]
       │
       ├── [Main Hall — Client]
       ├── [VIP Room — Client]
       └── [Bar Area — Client]

Scenario C — Backup / Redundancy

Run a second DjMirror Pulse as a client on a standby machine. If the primary display fails, point the output at the standby. The standby is always in sync and ready.

Performance Notes for Large Deployments

• The server accepts any number of clients simultaneously.
• Only configuration deltas are transmitted — bandwidth scales well even with many clients.
• Avoid running multiple instances on the same machine in production. All instances on one machine share the same config.json, audio input, Ableton Link, Spout/NDI outputs, and DMX interface. Use dedicated hardware per role.

Chapter 10: Troubleshooting

Connection Problems

Synchronization Problems

Log-Guided Diagnostics

Start both server and client with --console and compare logs side-by-side:

# Terminal 1 — Server
.\DjMirrorPulse.exe --server --console 2>&1 | Tee-Object server.log

# Terminal 2 — Client
.\DjMirrorPulse.exe --no-server --console --client http://192.168.1.50:8080 2>&1 | Tee-Object client.log

Chapter 11: Summary — Command Reference

Chapter 12: Related Documentation

• HTTP API Reference: docs_tech/docs_http_ws/README_HTTP_API_REFERENCE.md
• Configuration Parameters: docs_tech/docs_parameters/README_CONFIG_PARAMETERS.md
• NDI & Spout Output: NDI_SPOUT_OUTPUT_GUIDE.md (this manual set)