Migrating from WATCHOUT 6

If you have been running shows with WATCHOUT 6, much of what you know still applies — timelines, cues, the Stage metaphor, and the general production workflow all carry forward. However, the underlying architecture changed significantly in WATCHOUT 7. This article maps the old concepts to the new ones so you can transfer your expertise without starting from scratch.

Overview

The table below is a quick cheat-sheet of the major shifts. Each row is expanded in the sections that follow.

CategoryWATCHOUT 6WATCHOUT 7
Service modelTwo roles — Production Computer, Display Computer (Watchpoint)Independent services — Producer, Director, Runner, Asset Manager, and others
Process model32-bit — limited to ~4 GB of memory per process64-bit — uses available system RAM
Authoring loadProduction plays original content for the whole StageProducer plays low-resolution previews — much lighter on the authoring node
Editing workflowEdits made one cue at a timeMulti-select and multi-edit; Cue Window lists and filters every cue in the show
Online / OfflineExplicit online/offline toggle; edits staged before going liveAlways connected; changes propagate immediately
Asset managementPer-show distribution — assets belong to one showCentralized Asset Manager — assets are shared across shows
Asset formatPlays assets natively in their source codecOptimizes assets to a proprietary playback format; optional transcoding to other codecs
Color pipelineColor-agnostic, 8-bitColor-aware compositing in linear wide color space; HDR output up to 16-bit per component
Show file formatProprietary .watch format containing asset references.watch files store display config, timelines, and cues — assets live in the Asset Manager
DiscoveryIP-based addressingMulticast discovery (UDP 3011/3012); nodes identified by name
External controlTCP text protocol on ports 3039/3040Unified variable system — OSC, ArtNet, HTTP, MIDI, WO6 compat all map to WATCHOUT variables

Importing a WATCHOUT 6 show

WATCHOUT 7 includes a built-in importer for WATCHOUT 6 .watch files. Open Producer and choose File > Import WATCHOUT 6 Show… to convert a source file into a new WATCHOUT 7 show. The original WATCHOUT 6 file is not modified.

Most content transfers automatically:

  • Displays (position, resolution, warp, projector frustum, tier assignments)
  • Media references (images, video, audio, 3D models)
  • Timelines, layers, cues, and effects
  • Capture cues
  • Compositions and virtual displays

A few features are partially supported or skipped — display masks and certain tween types. The importer generates an import report at the end of each run listing anything that needs manual attention.

See Importing from WATCHOUT 6 for the full procedure, the complete list of imported items, and known limitations.

From two roles to independent services

In WATCHOUT 6, the architecture had two roles. The Production Computer ran the authoring application and controlled one or more Display Computers (Watchpoint). Two programs, two roles.

WATCHOUT 7 splits that model into a set of independent services. The four you interact with most are:

  • Producer — the authoring application where you build shows (replaces the Production Computer role).
  • Director — a coordination service that manages playback across all display nodes. It holds the show state and tells Runners what to do.
  • Runner — the display engine that renders output (replaces Watchpoint).
  • Asset Manager — a dedicated service for storing, optimizing, and distributing assets.

The split happened for practical reasons: separating authoring from coordination lets the Director run independently (even without a Producer connected), asset distribution can happen in the background without blocking playback, and each service can scale independently on different hardware.

The key mental-model shift: the Director is not the Production Computer. The Director is a headless coordination service that can run on its own. The Producer connects to a Director to author and monitor the show, but the Director keeps running when the Producer disconnects.

For small setups, all the services can still run on a single machine — the added complexity is entirely opt-in.

See Network Overview for the full technical picture of how the services communicate.

64-bit process model

WATCHOUT 6 is a 32-bit application. Each process is limited to roughly 4 GB of virtual address space, and typically less than 3 GB is usable in practice.

WATCHOUT 7 is fully 64-bit. Every service can address as much memory as the system provides, which allows larger asset caches, higher-resolution canvases, and more complex shows without hitting the 32-bit memory ceiling.

Executables

Under the hood, WATCHOUT 7 is composed of specialized executables that are started and managed automatically. Understanding what each one does helps when troubleshooting or planning deployments.

ExecutableRole
access-control.exeConfiguration window for what a remote Producer is allowed to do on this node — browse local folders for assets and accept software updates. Launched from the WATCHOUT Manager tray menu.
artnet-recorder.exeRecords Art-Net DMX streams to file for later replay. Optional install component.
asset-server.exeAsset Manager service — stores assets, runs the Optimizer pipeline, and distributes optimized files to Runners.
asset-watcher.exeMonitors designated folders and auto-imports new or changed assets into the Asset Manager.
audiorenderer.exeRenders audio output. Managed by the Runner.
device_capabilities.exeProbes the host's video and audio devices and reports the result to the Process Manager. Used for display detection and device enumeration.
director.exeHolds the show state, synchronizes timelines and Runners, and evaluates expressions. The Director-elected node also serves NTP time to the other nodes.
ltc-bridge.exeReads SMPTE linear timecode (LTC) input and feeds it to the Director. Optional install component.
midi-bridge.exeTranslates MIDI note, CC, and MSC messages into WATCHOUT variables. Optional install component.
nmos-controller.exeNMOS / ST 2110 control service. Handles device discovery and connection management for ST 2110 transports. Serves HTTP on port 3025.
operative.exeProtocol translation layer for OSC, Art-Net, HTTP REST API, and the WO6 compatibility protocol. Runs alongside the Director and connects to it.
optimizer.exeStandalone command-line tool that converts source media into WATCHOUT's playback formats. Invoked by the Asset Manager during import and also available for manual runs.
process-manager.exeThe back-end process behind WATCHOUT Manager (the desktop shortcut and tray icon). Present on every WATCHOUT host. Handles node discovery and service lifecycle — it decides which other executables to launch and monitors their health.
producer.exeThe desktop application for show authoring and control.
runner.exePer-node playback engine. Receives show data from the Director and drives the renderers.
splash_screen.exeSplash window shown on each output before a show is loaded. Displays the channel number and node identity for setup verification.
visualrenderer.exeRenders visual output to the connected displays. Managed by the Runner.

The Process Manager is the foundation — it runs on every node, discovers other nodes on the network via multicast, and starts or restarts services as needed. You never interact with it directly, but it is the reason WATCHOUT nodes can find each other automatically and recover from crashes.

The Operative deserves special mention because it is the single entry point for all external control protocols. Rather than each protocol having its own standalone service, the Operative translates incoming OSC, ArtNet, and HTTP messages into WATCHOUT's unified variable system, and routes outgoing messages back to the appropriate protocol.

Deployment configurations

Because the services are independent executables, you can distribute them across machines in whatever arrangement suits your production:

  1. All-in-One — a single computer runs Producer, Director, Runner, and Asset Manager, and can drive multiple outputs. Suitable for development, rehearsal, and smaller shows.
  2. Small Production — Producer and Director on one machine, with 1–3 separate Runner nodes driving displays.
  3. Large Production — a dedicated Producer workstation, a separate Director server, and many Runner nodes across the network.
  4. Installation (Headless) — the Director runs on a dedicated server with no Producer connected. Runners play the show autonomously, controlled by external systems via the Operative. Ideal for permanent installations that must run unattended.

System resilience

The distributed design provides built-in fault tolerance:

  • Producer can close and reopen without affecting the show — Producer is the user interface; show state lives in the Director. Closing Producer, intentionally or due to a crash, does not interrupt playback. In WATCHOUT 6, the Production application held the show state, so losing it meant losing control of the running show.
  • Runners continue playback if the Director is lost — once a Runner has received the show data, it keeps rendering even if the network connection to the Director drops.
  • Renderers maintain output if the Runner disconnects — the visual and audio renderers hold their last state, avoiding black screens during transient failures.
  • Services restart automatically — WATCHOUT Manager monitors all services and restarts any that crash, without manual intervention. The Director is a small service that recovers quickly.
  • Distributed processing eliminates single points of failure — no single machine needs to handle all tasks.

Always connected — no more online/offline

In WATCHOUT 6, you worked offline by default. You staged your edits, previewed locally, and then explicitly chose Go Online to push changes to the display computers. This two-step workflow gave you a safety net — nothing was live until you said so.

In WATCHOUT 7, there is no offline mode. When Producer is connected to a Director, the system is always live. Every edit you make — moving a layer, adjusting an effect, repositioning a display — propagates to the Runners immediately. Pressing Play is always a live action.

This means you need new habits to protect a running show:

  • Blind Edit Mode — work on a copy of a timeline (or composition), then Apply or Discard the edits. This is the closest equivalent to the old offline workflow. See Blind Edit Mode.
  • Hands Off — a timeline lock that prevents accidental edits during a performance.

The online command in the WO6 compatibility protocol is accepted but has no effect in WATCHOUT 7. If your control system sends it, nothing will break — it is simply a no-op.

For more detail, see Network Overview.

Centralized asset management

In WATCHOUT 6, assets were tied to the show. Each show carried its own set of media files, and the Production Computer distributed them to display computers automatically — but switching to a different show meant a different set of files.

In WATCHOUT 7, a dedicated Asset Manager service stores and optimizes assets independently of any show. Multiple shows can share the same assets, and the Asset Manager distributes them to Runners on demand. You import assets into the Asset Manager (or let the Asset Watcher auto-import from watched folders); switching between shows reuses files that Runners already have.

New capabilities that come with this approach:

  • Cross-show asset sharing — the same asset can be referenced from multiple shows without duplication.
  • Dynamic asset versioning — replace an asset and Runners pick up the new version without stopping the show.
  • Show consolidation — bundle all assets used by a show for archiving or transport.
  • Background transfer — asset distribution happens alongside playback without interrupting the show.

See Asset Manager for full documentation.

Asset optimization

WATCHOUT 6 plays assets in their native format. Reliability and playback performance depend on the codec each source file uses, which varies between source types.

WATCHOUT 7 optimizes every imported asset into a proprietary playback format designed for reliable, performant, and predictable playback. The Optimizer runs automatically on import and produces a Runner-ready version alongside the original. You can also transcode assets to other codecs through the Optimizer's settings when a specific output format is required.

The Optimizer also produces a low-resolution preview alongside the full asset. Producer plays back those previews rather than the originals, so the authoring node is far less hardware-intensive than the WATCHOUT 6 Production Computer, which had to play the original content for the entire Stage.

See Formats and Codecs for the list of supported source and output formats.

Color and HDR

WATCHOUT 6 is color-agnostic. The pipeline is 8-bit and does not account for the color space of source assets — what comes in is what goes out, regardless of how it was encoded.

WATCHOUT 7 is color-aware. Compositing happens in a linear wide color space, so assets encoded in different color spaces (sRGB, Rec. 709, Rec. 2020, Display P3) can be combined correctly on the same Stage. The output pipeline supports HDR with up to 16 bits per color component.

Show file format

WATCHOUT 6 used a proprietary show file format. WATCHOUT 7 also uses .watch files, but the content model is different: a .watch file stores display configurations, timeline data, and cue definitions — not assets. All assets live in the Asset Manager.

For importing a WO6 show into WATCHOUT 7, see the Importing a WATCHOUT 6 show section above and the dedicated Importing from WATCHOUT 6 reference.

Network discovery and failover

In WATCHOUT 6, display computers were configured by IP address. You typed in the IP of each Watchpoint and the Production Computer connected directly.

In WATCHOUT 7, nodes discover each other automatically via multicast on UDP ports 3011 and 3012. Each node has a name rather than a fixed IP address. As long as nodes are on the same subnet and multicast traffic is allowed, they find each other without manual configuration.

The name-based model also supports a cold-spare workflow. If a node fails or has to be taken offline for maintenance, swap in a replacement by renaming it to the original node's name — the rest of the show now reaches it without reconfiguration. The two machines must not be powered on at the same time; this is a manual swap, not automatic failover.

See Network Overview for subnet, VLAN, and switch configuration details.

External control and protocols

In WATCHOUT 6, external control used a text-based TCP protocol on ports 3039 (production) and 3040 (display). Control systems sent direct commands like run, halt, load, and gotoControlCue.

In WATCHOUT 7, external control is built around a unified variable system. All incoming protocols — OSC, ArtNet, HTTP, MIDI, the WO6 compatibility layer — are mapped to WATCHOUT variables. A timeline, a cue, or an asset property can be driven by any protocol through the same variable binding. This means you can mix and match protocols freely.

Available control surfaces in WATCHOUT 7:

  • HTTP REST API — the recommended protocol for new integrations. Structured, documented, stateless.
  • OSC — bidirectional, supports both input and output.
  • ArtNet / sACN — DMX-style channel control.
  • PSN — PosiStageNet for live tracking data.
  • MIDI Bridge — note and CC mapping.
  • LTC Bridge — SMPTE timecode input.
  • MSC — MIDI Show Control.
  • WO6 compatibility — ports 3039/3040 still respond to the classic text protocol.

The WO6 compatibility layer supports most legacy commands, but some are unimplemented (hitTest, standBy, setRate, and others). The online command is accepted but ignored.

If you have existing Crestron, AMX, or Extron integrations, they will work via the WO6 compatibility protocol with minimal changes. For new development, use the HTTP REST API.

See WATCHOUT 6 Protocol and External Control Overview for the full reference.

Keyboard and playback behavior

In WATCHOUT 6, pressing Space controlled the last active timeline from any window. WATCHOUT 7 keeps this behavior through Legacy keyboard mode in the Edit menu, which is on by default. Turn it off to make the playback keys — Space, Numpad 0, and Escape — work only when the Timeline window is focused. See Legacy Keyboard Mode.

Control cues also work differently. In WATCHOUT 6, a control cue targeted a single timeline by reference (This, Id, or Name). WATCHOUT 7 adds two new targeting modes:

  • List mode — target multiple specific timelines.
  • Filter mode — target timelines matching a pattern or tag.

See Control Cues for the full control-cue and targeting reference.

Multi-select and the Cue Window

WATCHOUT 6 edits are made one cue at a time. To change the same property on several cues, you edit each one individually.

WATCHOUT 7 supports multi-select and multi-edit: select any number of cues across timelines and change properties for all of them at once. The new Cue Window lists every cue in the show with filtering and sorting — useful for batch edits, audits, and finding cues by name, asset, or property without scrolling through timelines.

Running both versions

If you need to switch between WATCHOUT 6 and WATCHOUT 7 on WATCHPAX hardware, you can do so from Producer's Nodes window using the Switch to WATCHOUT 6 command. This triggers a full machine reboot and requires that WATCHOUT 6 is pre-installed on the node.

Each node also has per-protocol toggles in its properties — Art-Net, OSC, PSN, Web UI, WO6 (legacy control), and WO7 can be enabled or disabled individually. This lets you run WO7 playback while still accepting commands from a WO6-era control system, or shut off protocols on a node that does not need them.

See Software Updates for details on managing software versions across your nodes.