OLA, the distribution layer between control software and lighting fixtures

Why a distribution layer exists at all

Entertainment lighting is a protocol jungle, and that is the problem OLA addresses. The Digital Multiplex protocol DMX-512 and IP variants such as Streaming ACN are used to control lighting fixtures, and each has its own framing, its own addressing scheme and its own idea of what a universe is. A piece of control software that wants to drive a sACN rig and a DMX desk rig has to deal with all of that.

OLA provides the distribution layer that abstracts away the various protocols used. The stated benefit is concrete: authors of lighting control software can focus on generating the control information, rather than implementing support for different hardware devices and network protocols.

That framing tells you who it is for. If you are writing lighting control software, or a show controller, or a piece of tooling that has to talk to fixtures, OLA sits between your code and the wire. If you are a lighting designer choosing a desk, or an end user of a show, this is not your tool.

The platform story is also stated: OLA runs on Linux and Mac OS X, and some features will also work on Windows. That is a narrower commitment than a pure library, and it fits the design, since the core of the project is a long-running daemon.

The repository topics reinforce the scope, listing artnet, dmx, dmx512, dmxking, enttec, rdm, sacn, streaming-acn, protobuf, api and cli. Those tags are an honest index of what the protocol plugins cover.

olad, the plugins, and libola

OLA consists of three parts, and the README is precise about it: the daemon olad, the olad plugins, and the client library, libola. Understanding the split tells you most of what you need to know about how it runs.

olad is the process that owns the network. It talks to the fixtures, keeps universes in sync, and it is the thing that has to be running for anything to happen. The plugins are the protocol implementations it loads, and they live in the plugins directory in the tree. The client library, libola, is what your application links against to talk to the running daemon.

So the deployment model is a service plus a client, not a library you call in-process. Your control software talks to olad locally, and olad talks to the network. That has two consequences. It means the protocol handling happens in one place, so a bug fix or a new fixture quirk applies to everything using it. It also means there is a process boundary, and the failure modes of a daemon that is not running are your problem to handle.

The repository layout shows how much is protocol surface. There is a protoc/ directory, and protobuf appears in the topic tags, which is the inter-process wire format between client and daemon rather than a lighting protocol. There are separate packages for the client library and the server, visible in the libola.pc.in and libolaserver.pc.in files, the latter being the pkg-config template for the server side. There is a debian/ directory, a man/ directory for manual pages, and a data/ directory for the configuration and patch files the daemon uses.

The tree also carries the build machinery of an autotools project: configure.ac, Makefile.am, aminclude.am and libola.pc.in. That is a signal about the portability effort involved, and about what building from source will feel like.

Packages, downloads, and signed tags

OLA is distributed in a number of formats, including Debian and Ubuntu packages and MacPorts, and the OLA Downloads page is where the README points for more information. That matters for the first hour of adoption: if a packaged build exists for your distribution, you are not compiling a C++ autotools project to find out whether it works.

The project also takes release integrity seriously enough to document it. Tagged releases in the git repository are signed, and the README gives the two commands to check that. First you import the public key:

    $ git cat-file blob simon-pubkey | gpg --import

Then you verify the release tag itself:

    $ git tag -v 0.9.6

It is worth noting that the version used in the README's own example, 0.9.6, is older than the versions listed as recent releases. The documented procedure is what matters here, and it is the procedure to run before you deploy a binary that came from a mirror or a package feed.

From there, the documentation lives on the Open Lighting Architecture Docs site, and the README notes the pages are automatically updated from the git repository. That is a nice property for a project like this: the documentation you read tracks the code rather than lagging behind a release, and it includes examples on how to get started. The Getting Help page covers the mailing list and the IRC channel, which is where support for OLA is provided.

The client libraries: C++, Python, and an experimental Java one

Your application talks to olad through libola, and the C++ client is the primary one. The C++ Client is in the ola directory in the tree, and the README points to the C++ DMX Client API Tutorial for examples of how to use it.

The Python module is a build option rather than a default. It can be built by running configure with --enable-python-libs, and there are examples of how to use the Python API in the python/examples directory. That is the fastest route for scripting, for test harnesses, or for anyone who wants to poke at a running olad from a shell without writing C++.

The Java library is described as experimental and is built by running configure with --enable-java-libs. Experimental is the operative word: it is a build flag you opt into, and the README does not claim parity with the C++ or Python clients.

For plugin authors there is a separate path. The OLA plugins are located in ./plugins, and the README points to plugins/osc/README.developer.md for a walkthrough of an example. The OSC plugin matters more than it might look, because OSC is how control desks and show control systems talk to each other, and OLA's plugin architecture is how a site that needs a protocol nobody has written yet gets one.

The examples directory shows the breadth of what the client library can do. The file names cover an Art-Net client, an E1.31 client, an sACN streaming client, RDM discovery, a DMX console, a DMX monitor, a recorder, a timecode client, a latency measurement tool, a throughput measurement tool, and the show file format with OlaConfigurator, ShowLoader, ShowPlayer, ShowRecorder and ShowSaver. That list is a better summary of the project's capabilities than any marketing sentence.

Protocol conversion as a secondary use

The second use case in the README is one that does not require any of the C++ at all. OLA can be used to convert between different network protocols. With the use of a USB to DMX512 device, OLA can act as a DMX-over-IP to DMX512 gateway.

That is a genuinely useful thing to have, because it is the bridge between the modern IP world and the older physical DMX chain that a lot of installed fixtures still speak. Rather than buying a dedicated converter box, a machine with olad and a USB to DMX512 adapter can terminate a universe and hand it to the fixtures.

The wording is general too: convert between different network protocols, not just this one pair. Art-Net and sACN are the obvious cases, and both appear in the example file names. So the same daemon that acts as a gateway for one legacy rig can be bridging two IP protocols for another.

The constraint is that a USB to DMX512 device is required for the DMX side. OLA is the software; the serial link to the fixtures is a separate purchase, and a bad or underpowered adapter will show up as flaky output rather than as an error message.

Where the code is fresher than the packages

The maintenance picture needs two dates. The listed releases are 0.10.9 on 2023-02-26, 0.10.8 on 2020-11-22 and 0.10.7 on 2018-07-14. The last push to the repository, on the master branch, was on 2026-10-14.

So the branch is moving while the packaged releases are old, and by a wide margin. The badges at the top of the README show the continuous integration still running on the current tree: a build workflow, a Debian build workflow, a lint workflow, a Coverity scan, and a coverage service. There is also a ChangeLog, a NEWS file and a TODO file in the tree.

For an adopter, that gap has a concrete shape. The code you get from a distribution package is a 2023-era snapshot of a project whose master branch has moved on, and those two can differ in ways that matter for protocol behaviour, since a lighting protocol changes in small ways when a manufacturer ships new firmware. If you deploy the packaged version, you are choosing the packaged version's behaviour. If you build from master, you are choosing behaviour that the CI checks but that no package has shipped, and you are on the hook for building it yourself.

The version numbering also says something. The releases are 0.10.x, which reads as a project that has not yet committed to a stable interface, and a client library API that has not been declared stable is something to plan around if you are writing code that has to keep working.

Licensing, and what to check before you link it

The licence situation needs reading rather than summarising. The project listing records the licence as other, a custom licence GitHub cannot classify, with a pointer to the LICENSE file. The tree itself is more informative: there are separate COPYING, GPL, LGPL and LICENCE files at the top level, alongside examples/LICENCE.

That layout is the standard shape for a project that ships different terms for different parts, and OLA has a natural split between the client library that your application links against and the server side that talks to the network. The presence of both a GPL and an LGPL file suggests the terms differ between components, which is exactly the point at which a project like this needs care.

Do not take my reading of a directory listing as your compliance answer. Read COPYING, GPL, LGPL and LICENCE yourself, find out which terms attach to the parts you link or ship, and take the question to whoever owns licence compliance in your organisation. Whether your obligation triggers on linking libola, on distributing a binary that contains it, or on running a modified olad, is a question of facts about your deployment and your licence, not about the file names in a repository.

There is also a practical reason to care. This is software that drives physical hardware. The cost of a licensing question discovered after deployment is much higher than the cost of the same question answered before you write the first plugin.

Editorial conclusion

Adopt OLA when your control software needs to drive real fixtures over DMX-512 or sACN and you would rather not write protocol handling, discovery and failover yourself, and when you need its recorder and show player to inspect what a desk produced. Do not adopt it for a small installation that speaks one IP protocol, where a direct socket client is less code to own. Verify first which packaged release you can install, because the newest listed tag is 0.10.9 from 2023-02-26 while the master branch was pushed on 2026-10-14, and read the GPL, LGPL and LICENCE files in the tree before you link libola into a shipped product.

Frequently asked questions

Official sources

1. Issues
2. OpenLightingProject/ola on GitHub
3. Project website
4. README
5. Releases