OLA developer info

This attempts to describe the internal structure of OLA, in particular the classes that make up plugins. Read Using_OLA first to understand the Port/Device/Universe/Plugin terminology.

Core Classes

DmxBuffer

The DmxBuffer class allows DMX data to be passed around the code, while avoiding unnecessary copying. DmxBuffer is defined in include/ola/DmxBuffer.h

DmxBuffer data;  // new empty buffer
data.Size(); // size of the buffer, 0 to 512
data.Blackout();  // set all channels to 0
data.Set(data, length); // set the buffer from a uint8_t*
data.Get(data, &length); // copy the data buffer into the memory pointed to by data

Dmxbuffer data2 = data; // no copy

DmxBuffers are very similar to the boost shared_ptr

Closures & Callbacks

Closures & Callbacks are similar to function pointers, they allow both functions and methods to be invoked at a later time with data from either/both the time the Closure is constructed and the time the Closure is executed.

All Closures/Callbacks have a Run() method, which is how the Closure is called. Closures take no arguments at exec time, Callbacks take one or more arguments at exec time.

SelectServer & Sockets

The SelectServer is the dispatcher at the core of OLA. It waits for events, and when an action occurs calls the specified method.

Logging

The logging macros are defined in include/ola/Logging.h. Logging outputs behave like streams:

OLA_FATAL << "foo";
OLA_ERROR << "bar";
OLA_INFO << "baz";
OLA_DEBUG << "bat";

Plugin System

We'll use plugin to refer to the entire module (Plugin, Devices & Ports), and Plugin to refer to the class that inherits from Plugin.

Plugins create and register Devices, which each consist of 0 (obviously not useful) or more Ports. A Plugin generally does a bit of work when it starts to detect devices, then leaves all work to the individual Devices and Ports.

PluginAdaptor

The PluginAdaptor is the interface between plugin code and the core OLA objects. Each Plugin object has a pointer to a plugin adaptor in the instance variable m_plugin_adaptor.

Plugins

The AbstractPlugin interface is defined in include/olad/Plugin.h. The Plugin class implements most of this interface, and leaves Id(), PluginPrefix(), StartHook(), StopHook(), SetDefaultPreferences() and Description() to be implemented by the child classes.

The startup sequence for a Plugin object is:

• From within DynamicPluginLoader::LoadPlugins an instance of the plugin is created
• If the ShouldStart() method returns False, nothing else happened the Start() method is called.
• The Start() method calls LoadPreferences() which in turn calls SetDefaultPreferences(), this last method gives the Plugin the opportunity to setup the Preferences object.
• if SetDefaultPreferences() doesn't fail, StartHook() is called where new Devices are created. m_plugin_adaptor->RegisterDevice() should be called to add new Devices.

During the shutdown sequence:

• Stop() is called, which in turn calls StopHook()
• StopHook should call m_plugin_adaptor->UnregisterDevice() for any devices registered during the start phase.
• delete is then called on the Plugin object

At any time a the following methods can be called:

• Id()
• Name()
• Description()

Devices

The interface to Devices is defined in include/olad/Device.h as AbstractDevice, again the Device class implements most of this interface, leaving the derived classes to fill in a couple of methods:

• DeviceId() - returns a unique persistent string identifying this device
• StartHook() - this should create the port objects for a device.

Ports

Ports are the objects that actually read/write DmxBuffers. Defined in include/olad/Port.h there is the base interface Port, and then two child interfaces, InputPort and OutputPort. The BasicInputPort and BasicOutputPort provide partial implementations for these two interfaces.

At a minimum , an OutputPort needs to provide the following methods:

• WriteDMX(const DmxBuffer &buffer, uint8_t priority)
• Description()

And an InputPort needs to provide:

• ReadDMX()
• Description()

A call to ReadDMX() is triggered by calling DmxChanged() on a InputPort object. This causes the universe the port is bound to to fetch the new DMX data. Both ReadDMX() and WriteDMX() must be non-blocking, blocking here will delay the main processing loop. To satisfy this, most ports use this sequence of events:

• register a Socket for reading with the SelectServer

// some time later

• receive notification that there is new data on the socket
• read the data and copy it to a buffer
• call DmxChanged() to notify the bound Universe we have new data
• the Universe then calls ReadDMX()

Often more than one port will use the same file descriptor. This means the device is responsible for reading the data and dispatching to the right port.

Here's an example of how dmx data is received from the UsbPro Device.

The UsbProDevice will have been registered using plugin_adaptor->RegisterSocket(). When input becomes available the following sequence happens:

 device->action() // signals the device that new data is available
   widget->recv() // tells the widget to read more data
     widget->do_recv() // reads the data from the fd
       widget->handle_cos() // handles the change-of-state message from the widget
         device->new_dmx() // signal the device that new dmx data has arrived 
          port->DmxChanged() // signal the universe that new dmx data has arrived
            // if this port is bound to a universe, the universe will then call
            port->ReadDMX()
              device->get_dmx()
               widget->get_dmx()

Of course, the plugin authors are free to implement this however they like.

Config Messages

Config messages are handled a little differently for two reasons:

* The configure() method in a plugin has to return a response immediately. We don't want to block because we'll delay all lla processing. The new RPC subsystem removes this limitation.
* Sending a PARAMETER_REQUEST to the widget doesn't generate a response immediately (in fact it may not generate one at all).

To work around this, we send a parameter_request when we start the device, and then anytime we set parameters. In the meantime we store the parameters in the widget object and return those. The sequence looks like:

 device->configure()
   device->config_get_params()
     widget->get_parms()

• What is the interface between the LLA core and LLA plugins?

 See above and the files plugin.h, device.h and port.h. The create() call will be passed a PluginAdaptor object which can then be used to register/unregister file descriptors, loop functions, timeouts and devices.

• What is the interface between the LLA core and other apps/clients to LLA like QLC?

 All clients should use the LlaClient library. This needs better documentation.

• How is functionality split between the usbpro plugin and the example program?

The example program constructs configuration request messages and sends them (using LlaClient) to the Lla Core. The core routes this message to the plugin, which then returns a response message. This response is passed back to the client.

• When llad is started it loads all available plugins. Always?

Ideas for easy configuration

For some users, it will be useful to have a "auto-connect" feature. When a attached device is discovered (either when LLA i started or when a new device is attached), the user could be asked if the available ports (input as well as output) should be patched to the lowest available universes.

• Enable auto-connect ( OFF|connect whatever comes first|connect by stored patch layout)
• Save a given combination of devices (just by type or with unique ID's from serial numbers, USB device ID's etc)

Which devices cannot be autodetected?

About device config messages

We need a way to tune settings on a port/device that the LLA Core doesn't know about. To enable this, the LlaClient provides a method dev_config(unsigned int dev, LlaDevConfigMsg *msg)

The LlaDevConfigMsg is an interface which declares one method: pack(uint8_t buffer, unsigned int length). On the device side, we declare a method configure(uint8_t *request, int length)

So to use this:

On the client

 MyObserver::dev_config(unsigned int dev, uin8_t *res, unsigned int length) {
   MyLlaDevConfigMsg msg = parse_message(data, length);
   // do something with the result
 }
 
 int main() {
   // all the setup code
 
   MyObserver observer;
   // the observer gets the dev_config() callback
   lla_client->set_observer(&observer);
 
   MyLlaDevConfigMsg msg;
   // set some fields
   msg.foo = 1
   lla_client->dev_config(device_id, &msg); //calls pack() on the message
 }

In the device:

 MyDevice::configure(data, length) {
   MyLlaDevConfigMsg msg = parse_message(data, length);
   // do something with the message
 
   MyLlaDevConfigMsg *response = new MyLlaDevConfigMsg();
   // response is deleted by the lla core
   return response;
 }

The tool app "lla-usbpro"

The purpose is to set and get the settings that reside in the USB Pro box.

The communication with USB Pro's seems to go via the LLA core, and lla-usbpro registers as a LLA client, and uses some event handlers.

As defined in the device spec. (PDF from Enttec):

label=3 response

• 1. data byte= Firmware version LSB. Valid range is 0 to 255.
• 2. data byte=Firmware version MSB. Valid range is 0 to 255.
• 3. data byte=DMX output break time in 10.67 microsecond units. range=[9-127] (96.03 - 1355.09 micro seconds)
• 4. data byte=DMX output Mark After Break time in 10.67 microsecond units. range=[1-127] (10.67 - 1355.09 micro seconds)
• 5. data byte=DMX output rate in packets per second. range=[1-40]
• x. data byte= some user configuration of the requested size

The serial number is is decoded (from 4 bit Binary Coded Decimal) in lla-usbpro, not the plugin.

Unsupported USB devices

• Peperoni Rodin1 (but this is supported directly by QLC)
• Peperoni USBDMX21
• USB DMX from usbdmx.com
• Sandsys UMX2
• Sandsys UMX4

Peperoni and usbdmx are probably easy to implement. The specs and source code examples are available.