xLights: A C++ Sequencer for Light Shows, Built for Cross-Platform Control

What xLights Solves for Light Show Creators

xLights addresses a specific pain point for hobbyists and professionals who run synchronized light shows, often for holidays or events. The problem is that lighting hardware comes in many protocols, and sequencers are often tied to a single vendor or format. xLights provides a unified environment where you can create sequences, organize them into playlists, schedule those playlists, test your hardware, and convert between different sequencer formats. This is for people who have moved beyond simple blinky lights and need a tool that treats a light display as a programmable system. The README describes it as an 'object oriented program,' which hints at a design where elements like models, effects, and controllers are treated as objects you can manipulate. The intended user is someone comfortable with installing development packages and possibly building from source, because the project does not offer a one-click installer for most platforms, only Ubuntu packages via a Launchpad PPA.

Under the Hood: C++, wxWidgets, and a Modular Driver Layer

The core of xLights is written in C++ and relies on wxWidgets as a cross-platform abstraction layer, which means the same codebase runs on Linux, macOS, and Windows. The README specifies a minimum wxWidgets version of 3.1.5, and the provided makefile can download and build wxWidgets automatically, including a patch for bitmap button sizing. This patch is a small but telling detail: it shows the project is willing to modify upstream dependencies to fix UI issues. The driver layer is split into USB and E1.31 (sACN) drivers, which are the two common ways to talk to lighting controllers. The architecture also includes optional GPU acceleration via Vulkan, with compute kernels compiled to SPIR-V at build time using glslc. This is a modular design where the Vulkan backend can be disabled with a build flag, and if no Vulkan loader is present at runtime, it falls back to CPU rendering. Similarly, hardware video decode uses FFmpeg's generic hwaccel API, so VA-API is resolved at runtime through the distro's libva, not linked directly. This layered approach keeps the core lightweight but means you must install the right runtime libraries to get full performance.

Building xLights on Linux: A Realistic Look at Dependencies

The README is explicit that Ubuntu 24.04 is the minimum supported Linux release, and that is the only baseline continuously verified. Fedora 42 is also tested, but other distributions may break. To build locally, you need a long list of development packages: build-essential, libgtk-3-dev, libgstreamer1.0-dev, freeglut3-dev, libavcodec-dev, libsdl2-dev, libcurl4-openssl-dev, liblua5.3-dev, and more. The list includes libegl-dev for Wayland support, which is a sign that the UI is not just X11-only. The build process uses a makefile, and cbp2make is recommended to generate project files, though it is optional. On Fedora, cbp2make is not in the official repos, so you must build it manually from GitHub. This is a barrier for casual users. The README also notes that without libavahi-compat-libdnssd-dev, mDNS-based controller discovery (like WLED) silently compiles out, with no build error. That means you could build a seemingly successful binary and later discover it lacks a feature you expected. This is a real failure mode for adopters who skip the dependency list.

Getting It Running: Docker, Nightly Builds, and the Ubuntu PPA

For users who do not want to mess with their local system, the README provides a Docker-based build path. You can pull a pre-made build image and run a container to produce a build or an AppImage. The commands are straightforward: docker build -t xlights-build from the xlights-build-docker repo, then docker run --name buildvm xlights-build /bin/bash Recipe. This isolates the build environment, which is helpful if you are on a non-supported distro. For end users, the README points to an Ubuntu PPA at code.launchpad.net, which provides prebuilt packages. The project also publishes nightly builds and versioned releases like 2026.16 and 2026.15, with the nightly being the most recent. This release cadence suggests active development, but it also means you are either on a nightly or a versioned release that may not be as thoroughly tested. The Docker approach is the most reliable way to get a consistent build, but it requires Docker knowledge and downloads a large image. The PPA is simpler but limited to Ubuntu users.

GPU and Video Acceleration: Optional but Finicky

Two performance features stand out: Vulkan-based GPU rendering and VA-API hardware video decode. The Vulkan path compiles compute shaders at build time using glslc, which is a required build tool. The Vulkan headers and loader are vendored as submodules, so nothing Vulkan is linked at build time; volk loads the driver at runtime. This is a clean design, but it means you must install libvulkan1 and mesa-vulkan-drivers at runtime, or xLights logs 'no Vulkan loader' and falls back to CPU. The README says to enable it under Preferences > Other > GPU rendering. For NVIDIA users, the proprietary driver provides Vulkan. Hardware video decode goes through FFmpeg's hwaccel API, so there is no build-time dependency, but you need a VA-API driver like intel-media-va-driver or mesa-va-drivers. The README suggests running vainfo to confirm the driver initializes before relying on it. This is a practical tip, but it also highlights that these features are not plug-and-play. If you skip these runtime packages, you get a working but slower xLights. For large shows with many effects, that could be a significant performance hit.

A Genuine Limitation: Silent Feature Compilation and Platform Support

The most concerning limitation is the silent compilation of mDNS support. The README warns that without libavahi-compat-libdnssd-dev, the dns_sd.h header is unavailable, and mDNS-based controller discovery silently compiles out. This means WLED controllers will not be auto-discovered, but the build succeeds without any error. For a user who expects to find their WLED devices on the network, this is a confusing failure. The only clue is the absence of the feature, not a build warning. Another limitation is the narrow supported platform range. The README states Ubuntu 24.04 is the minimum, and older releases may work but are not tested. This is a realistic constraint, but it means that if you are on Ubuntu 22.04 or Debian, you are on your own. The project also requires wxWidgets 3.1.5 and SDL2 2.0.5 or later, which may not be available in older distro repos, forcing you to build those from source. For a tool that aims to be cross-platform, this Linux-specific fragility is a trade-off. On Windows and macOS, the situation may be different, but the README does not detail those build paths, so you cannot assume they are easier.

Alternatives: How xLights Compares to Other Sequencers

The main alternative to xLights is Vixen Lights, another open-source sequencer. Vixen Lights is written in C# and runs on .NET, which gives it a different deployment model: it is easier to install on Windows, but Linux support is less native. xLights uses C++ and wxWidgets, which allows a single codebase across platforms, but at the cost of a more complex build. The key difference is that xLights has built-in E1.31 and USB drivers, while Vixen Lights relies on plugins for controller communication. This means xLights may have more direct support for a wider range of controllers out of the box, but the plugin architecture of Vixen Lights allows for more flexible third-party extensions. Another difference is that xLights includes a scheduler, while Vixen Lights often requires separate scheduling tools or manual setup. For users who want a single application to design, schedule, and run shows, xLights is more integrated. For users who prefer a modular ecosystem and are on Windows, Vixen Lights might be simpler. The choice depends on your hardware and your willingness to deal with the build process.

Maintenance and Upgrade Cost: What the Repository Shows

The repository shows active maintenance, with the last push on 2026-08-29 and a nightly release on the same date. The versioned releases, 2026.16 and 2026.15, suggest a monthly or bi-monthly release cycle, which is frequent. This means you can expect regular updates, but also that you need to keep up with them to get bug fixes and new features. The GPL-3.0 license is important: if you modify xLights and distribute it, you must make your source code available under the same license. This is not a problem for personal use, but it could be a concern for commercial products that embed xLights. The upgrade cost is moderate: because the project uses submodules for Vulkan dependencies, you need to do a recursive submodule checkout when cloning, and you may need to update those submodules when pulling new versions. The Docker build path can be reused, but you may need to rebuild the base image if the Recipe changes. Overall, the maintenance burden is on the user to stay current with releases and to ensure their system dependencies match the requirements. There is no LTS version mentioned, so you cannot rely on a stable branch for years.

Editorial conclusion

Adopt xLights if you need a full-featured, cross-platform sequencer for pixel or traditional lights, especially if you already work with E1.31 or USB controllers and want playlist scheduling and hardware testing in one tool. Avoid it if you lack the patience for a complex build or need a stable, long-term support release, since only nightly and versioned releases are offered and the minimum Linux baseline is Ubuntu 24.04. Before adopting, verify that your controllers are supported by the drivers, check that your GPU has Vulkan and VA-API support if you want acceleration, and confirm that your distribution meets the wxWidgets 3.1.5 and SDL2 2.0.5 requirements. The project is actively maintained with regular releases, but you must be prepared to handle build-time dependencies and occasional silent feature compilation, such as mDNS discovery without avahi.

Official sources

1. Official README
2. Project repository
3. Release notes