- 1 General
- 2 Universes
- 3 Plugins
- 4 Hardware
- 5 Extending
Can I use OLA in my project?
That depends on the project. libola is licensed under LGPL which means it can be used from commercial software. olad is licensed under the GPL which means any plugins added to olad must be GPL compatible.
Why aren’t my settings saved when I disconnect power from the Raspberry Pi?
olad only saves the settings during when the daemon is stopped. There is a long standing feature request to save settings whenever an attribute is changed. To work around this, configure olad with the settings you want, then stop olad (either from the web UI or the command line). At this point you can power cycle the Pi and the settings will be restored.
Can I use Universe 0?
olad universes can range from 0 to 65535. That said, some plugins like sACN don’t support universe 0. We suggest starting from Universe 1.
ArtNet uses a very complicated addressing scheme. ArtNet universes are described in the Net:Subnet:Port notation.
- Port addresses are 4 bits (0-15). Artistic License gear usually has a 8 position rotary switch that sets the port address for each port.
- Subnet address are 4 bits (0-15). Artistic License gear usually has a 8 position rotary switch that sets the subnet address for the node.
- Net addresses are 7 bits (0-127) but are only found on ArtNet3 devices. Pre-ArtNet3 the net address is treated as 0.
Putting this together, the address 0:1:2 means Net 0, SubNet 1, Port 2.
In OLA, the net & subnet values are set in the ola-artnet.conf file. The Port Address is determined for the universe that the ArtNet port is patched to, universe 0 -> port address 0, universe 1 -> port address 1, universe 15 -> port address 15, universe 16 -> port address 0 and so on.
What OSC formats are supported?
- blob: a OSC-blob
- float_array: an array of float values. 0.0 – 1.0
- individual_float: one float message for each slot (channel). 0.0 – 1.0
- individual_int: one int message for each slot (channel). 0 – 255.
- int_array: an array of int values. 0 – 255.
- Single channel ints & floats
Why is the output delayed with OLA version 0.8.33?
The 0.8.33 release had a bug the defaulted the SPI speed to 100kHz instead of 1MHz. To fix this change the <device>-spi-speed setting in ola-spi.conf.
What is the difference between the different USB plugins?
Serial USB (ola-usbserial.conf) is used for USB devices that appear as a FTDI serial port and use a external micro processor to generate the DMX signals. This includes USB devices that implement the Enttec USB Pro messages.
USB DMX (ola-usbdmx.conf) is used for USB devices that do not appear as serial ports and instead use custom USB protocols between the host (PC) and the device. The plugin uses libusb to communicate with the device.
FTDI USB DMX (ola-ftdidmx.conf) is for the ‘dumb’ FTDI devices. These have no external microprocessor and rely on the host to control the DMX timing. Examples of this type of device are the Enttec Open DMX USB.
Enttec Open DMX (ola-opendmx.conf) is similar to FTDI USB DMX, but it uses the Open DMX kernel module. Since this uses a kernel module it’s only used on Linux.
Can you add support for the <insert-name-here> device?
Adding support for new devices generally requires:
- Someone with C++ programming skills
- Someone with access to the new device.
Over the years, we’ve found that the process works best if 1) and 2) are the same person. Even though the Internet makes things easier, trying to debug problems remotely consumes an inordinate amount of time, and requires scheduling around day-jobs, family, etc. often across different timezones.
Often tools like logic analyzers, DMX / RDM sniffers, DMX / RDM test devices, and USB sniffers are required during development. Without these the experience is frustrating for everyone involved.
With that in mind, if you think you have the skills & equipment to add support for a device, by all means write the code and open a pull request. Otherwise the recommended way is to donate a device to one of the main contributors and have them work on it.
What are the recommended USB Device to use with OLA?
The following is entirely Simon’s opinion, the Open Lighting Project doesn’t endorse products.
For each category I list my top picks and all devices within the category can be considered equal. This list only considers using the device with OLA, rather than the full suite of software available for each interface. Since manufacturers send me hardware for free, I don’t consider price in my recommendations. YMMV.
For Sending DMX:
- Anyma uDMX, no opto-isolation
- DMX USB Pro
- DMX USB Pro MK II
- ultraDMX Micro, no opto-isolation
- ultraDMX Pro (discontinued)
For receiving DMX:
For acting as an RDM controller:
Interfaces I definitely wouldn’t use:
- Open DMX USB, no microprocessor, the host is responsible for signal timing.
- Velleman K8062, the design severely limits the update rate.
- Almost anything you find on eBay / Amazon.
How should I add support for a new Protocol / Device?
If you’re looking to add support for a new protocol or device, the easiest way to get started to to write an OLA Client. By keeping the logic separate from olad, it means you can focus on the new protocol / device without having to worry about integrating with olad.
Once the code is working correctly, it can be added as a OLA Plugin.
Some things to consider when deciding between a client and a plugin:
- Since plugins are linked with olad, they must be licensed under the GPL or a GPL compatible license.
- Plugins included in the main tree will be maintained if the plugin API changes. If your plugin isn’t included in the main tree it may break between releases.
- Plugins will generally perform better than clients, since they run in the same process as olad.
- Plugins must be written in C++. Clients can be written in any language with an OLA Client API.