wiki.openlighting.org - User contributions [en]

OLA developer info

2008-11-13T20:57:54Z

65.57.245.11: /* The tool app "lla-usbpro" */

''Or [[LLA]] code documentation''
Link to the [[LLA | LLA main page]].

== Drivers and platforms ==
LLA compiles on Linux and Mac and probably also Windows, but not all drivers work everywhere (yet). Here the status can be listed.

Supported Devices/Protocols:
{| border=1
! '''Driver'''!! Linux !! '''Mac OS X''' !! '''Windows'''
|-
|| [[:Category:ArtNet|ArtNet]] || Linux=Yes || ?? || ??
|-
|| [[:Category:ShowNet|ShowNet]] || Linux=Yes || ?? || ??
|-
|| [[:Category:ESP Net|ESP Net]] || Linux=Yes || ?? || ??
|-
|| [[:Category:Sandnet|Sandnet]] || Linux=Yes || ?? || ??
|-
|| [[DMX USB Pro]] || Linux=Yes || ?? || No
|-
|| [[Open DMX USB]] 1) || Linux=Yes || ?? || No
|-
|| [[DMX 4 Linux]] || Linux=Yes || ?? || No
|-
|| [[StageProfi]] || Linux=Yes || ?? || No
|-
|| [[:Category:Pathport|Pathport]] || Linux=in testing || ?? || No
|-
|| [[E1.31]] / [[ACN]] || Linux=development started || ?? || No
|}

Note 1): Support through the [http://www.erwinrol.com/index.php?opensource/dmxusb.php Linux kernel module from Erwin Rol], as detailed in [[LLA, OpenDMX USB and Q Light Controller Tutorial]].

Unsupported USB devices:
* [[Peperoni Light| Peperoni]] [[Rodin1]] (but this is supported directly by [[QLC]])
* [[Peperoni Light|Peperoni]] [[USBDMX21]]
* [[Anyma uDMX]]
* [[USB DMX]] from usbdmx.com
* [[Sandsys]] [[UMX2]]
* [[Sandsys]] [[UMX4]]
* [[Velleman K8062]] (no developer info available?)

=== Plugin system ===
* What is the structure of the plugins?

I'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 or more Ports. A Plugin generally does a bit of work when it starts, then leaves all work to the individual Devices and Ports.

This is the lifecycle of a Plugin object:
The create() function is called with a pointer to a PluginAdaptor, this returns a new instance of the Plugin.
Obviously the constructor is called - use this to init variables but any real work should be done later.
Plugin.start() is called, which calls start_hook()
Within start_hook, the Plugin should create Devices and register them by calling plugin_adaptor->register_device(device).
...
At any time we may call get_id(), get_name(), get_desc() on the Plugin.
...
Plugin->stop() is called, which calls stop_hook().
The Plugin should unregister any devices created in start_hook()
The destroy() function is called. This should delete the Plugin created in create().

* So how do devices / ports work?

Devices have one or more ports (accessible by port_count() and get_port(i)).
Ports are where the action happens. They need to provide the following methods:
read(uint8_t *, unsigned int)
write(uint8_t *, unsigned int)

Universes will then use these methods to read/write data from a port. Write is self explanatory, a call to read is triggered by port->dmx_changed(). These calls need to be non-blocking, blocking here will delay the main processing loop. To satisfy this, most ports use this sequence of events:

- register a file descriptor for reading
// some time later
- receive notification that there is new data
- read the data and copy it to a buffer
- call dmx_changed() to notify the Universe we have new data
- then Universe then calls read()

Often more than one port will use the same file descriptor which is owned by the Device. This means the device is responsible for reading the data and dispatching to the right port. See below for an example.

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

The UsbProDevice will have been registered using plugin_adaptor->register_fd(). 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->dmx_changed() // signal the port that new dmx data has arrived
// if this port is bound to a universe, the universe will then call
port->read()
device->get_dmx()
widget->get_dmx()

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

* I have difficulties to track the flow of data from it is fetched from the USB Pro until it is printed to the console by the app lla_usbpro. Some diagrams over the structure and data flow diagrams, or text that gives a good overview would be nice

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.

* What is it with the hidden web server?

That's coming in the next version. It's not checked in yet.

* 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?

== Ideas for QLC integration ==
''Here is room for YOUR writing :-)''

== About devince 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.

OLA developer info

2008-11-13T17:21:18Z

65.57.245.11:

OLA developer info

2008-11-13T17:05:24Z

65.57.245.11:

Open Lighting Architecture

2008-01-15T22:47:26Z

65.57.245.11:

Link: http://www.nomis52.net/?section=projects&sect2=lla&page=llaintro 
{{Features|free=yes|tx=yes|rx=yes|linux=yes}}
[[Image:Llad_home.png|right]]

LLA allows DMX sent using various DMX over IP protocols to be converted from one format to another. This enables devices from different manufacturers to talk to each another (for example a [[Strand_Lighting|Strand]] Console can send DMX to an [[Enttec]] [[DmxEtherGate MKII|EtherGate]]).

LLA Live is a stand-alone bootable cd containing software from the Linux Lighting Architecture project.

When combined with a physical DMX interface such as the [[DMX USB Pro]], LLA Live can send and receive data from traditional wired DMX networks.

Supported Devices/Protocols:
* [[:Category:ArtNet|ArtNet]]
* [[:Category:ShowNet|ShowNet]]
* [[:Category:ESP Net|ESP Net]]
* [[:Category:Sandnet|Sandnet]]
* [[DMX USB Pro]]
* [[Open DMX USB]] (through the [http://www.erwinrol.com/index.php?opensource/dmxusb.php Linux kernel module from Erwin Rol], as detailed in [[LLA, OpenDMX USB and Q Light Controller Tutorial]])
* [[DMX 4 Linux]]
* [[StageProfi]]

Under development:
* [[:Category:Pathport|Pathport]] (in testing)
* [[E1.31]]

Documentation:
* [[Using LLA]] - A basic introduction
* [[Building LLA]] - How to get it compiled
* [[Using the Python libraries]]
* [[LLA Tips & Tricks]]
* [[LLA Sandnet Tutorial]] - Setup Horizon using Sandnet and LLA
* [[LLA and Q Light Controller Ubuntu Tutorial]] - Setup LLA on Ubuntu/Debian-type distro with QLC

Availability:

Sources (via git)

http://www.nomis52.net/git/lla
http://www.nomis52.net/git/lla-examples

Debian Packages:

http://www.nomis52.net/data/debian

RPMS:

http://rpms.netmindz.net/

Live CD (iso):

[https://sourceforge.net/project/showfiles.php?group_id=126566&package_id=192352 Sourceforge]

There is a project underway to build packages for OpenWrt. See http://lists.culturebase.org/cgi-bin/mailman/listinfo/lla-openwrt for more details.

[[Category:ArtNet]]
[[Category:ESP Net]]
[[Category:Sandnet]]
[[Category:ShowNet]]
[[Category:Utilities]]

Manolator

2007-12-22T01:15:58Z

65.57.245.11: Replacing page with 'Link: http://www.freedmx.com/ {{Features|win=yes|tx=yes}} right The Manolator is a free DMX interface which provides up to 256 DMX channels. [...'

Link: http://www.freedmx.com/ 
{{Features|win=yes|tx=yes}}
[[Image:Manolator.jpg|right]]

The Manolator is a free DMX interface which provides up to 256 DMX channels.

[[Category:Parallel Port]]

Martin

2007-12-22T01:14:54Z

65.57.245.11:

Link: http://www.martin.com
[[Image:Martin.jpg|right]]
A recognised leader in the entertainment technology field, Martin has a reputation for delivering innovative and reliable products.

<div align="center"><div style="width:300px; border: 1px solid #0000ff; padding: 3px; background: #cef2e0; align:center">
Contact Information: 

Olof Palmes AllÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂ© 18
DK-8200 ÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂrhus N
Denmark

Tel. +45 87 40 00 00
</div></div>

Products by Martin:

* [[Martin Light Jockey]]
* [[Ether2DMX]]
* [[Optosplitter]]

[[Category:Companies]]

Category:Companies

2007-12-22T01:13:17Z

65.57.245.11: Replacing page with 'Manufacturers only. Please do not list resellers.'

Manufacturers only. Please do not list resellers.

Martin Light Jockey

2007-10-16T02:32:17Z

65.57.245.11:

Link: http://www.martin.com/product/product.asp?product=lightjockey 
Made by: [[Martin]] 
{{Features|win=yes|tx=yes|midi=yes}}

Martin LJ

[[Category:Controllers]]

Products

2007-10-16T02:31:47Z

65.57.245.11:

__NOTOC__

The products are categorized by their '''type''', their '''use''' etc.

== Accessories ==

* [[:Category:Adapters | Adapters]]
* [[:Category:Clothing | Clothing]]
* [[:Category:Splitters & Mergers | Splitters & Mergers]]
* [[:Category:Testers | Testers]]

== Computer Interfaces ==

* [[:Category:Parallel Port| Parallel port interface]]
* [[:Category:Serial| Serial port interface]]
* [[:Category:USB | USB interface]]

== Consoles ==

* [[:Category:Consoles |Consoles ]]

== Ethernet Interfaces ==

* [[:Category:ArtNet| ArtNet]]
* [[:Category:ESP Net|ESP Net]]
* [[:Category:Other | Other types]]
* [[:Category:Pathport | Pathport]]
* [[:Category:Sandnet|Sandnet]]
* [[:Category:ShowNet|ShowNet]]

== Software ==

* [[:Category:Controllers|Controllers]]
* [[:Category:Drivers / Libraries|Drivers / Libraries]]
* [[:Category:Utilities|Utilities]]
* [[:Category:Video / Visualisation|Video / Visualisation]]

OLA Python API

2007-10-12T01:02:30Z

65.57.245.11:

document this [simonn]

Open Lighting Architecture

2007-10-12T01:01:23Z

65.57.245.11:

Link: http://www.nomis52.net/?section=projects&sect2=lla&page=llaintro 
{{Features|free=yes|tx=yes|rx=yes|linux=yes}}
[[Image:Llad_home.png|right]]

LLA Live is a stand-alone bootable cd containing software from the Linux Lighting Architecture project.

LLA allows DMX sent using various DMX over IP protocols to be converted from one format to another. This enables devices from different manufacturers to talk to each another (for example a [[Strand_Lighting|Strand]] Console can send DMX to an [[Enttec]] [[DmxEtherGate MKII|EtherGate]]).

When combined with a physical DMX interface such as the [[DMX USB Pro]], LLA Live can send and receive data from traditional wired DMX networks.

Supported Devices/Protocols:
* [[:Category:ArtNet|ArtNet]]
* [[:Category:ShowNet|ShowNet]]
* [[:Category:ESP Net|ESP Net]]
* [[:Category:Sandnet|Sandnet]]
* [[DMX USB Pro]]
* [[Open DMX USB]] (through the [http://www.erwinrol.com/index.php?opensource/dmxusb.php Linux kernel module from Erwin Rol], as detailed in [[LLA, OpenDMX USB and Q Light Controller Tutorial]])
* [[DMX 4 Linux]]
* [[StageProfi]] (in testing)

Under development:
* [[:Category:Pathport|Pathport]] (in testing)
* [[E1.31]]

Documentation:
* [[Using LLA]] - A basic introduction
* [[Building LLA]] - How to get it compiled
* [[Using the Python libraries]]
* [[LLA Sandnet Tutorial]] - Setup Horizon using Sandnet and LLA
* [[LLA and Q Light Controller Ubuntu Tutorial]] - Setup LLA on Ubuntu/Debian-type distro with QLC

Availability:

Sources (via git)

http://www.nomis52.net/git/lla
http://www.nomis52.net/git/lla-examples

Debian Packages:

http://www.nomis52.net/data/debian

RPMS:

http://rpms.netmindz.net/

Live CD (iso):

[https://sourceforge.net/project/showfiles.php?group_id=126566&package_id=192352 Sourceforge]

There is a project underway to build packages for OpenWrt. See http://lists.culturebase.org/cgi-bin/mailman/listinfo/lla-openwrt for more details.

[[Category:ArtNet]]
[[Category:ESP Net]]
[[Category:Sandnet]]
[[Category:ShowNet]]
[[Category:Utilities]]

Drivers and software

2007-01-10T02:01:39Z

65.57.245.11:

There is a number of ways to get a controller application to send DMX data to a hardware interface (that can send the data out on your DMX wire).

Sometime the driver is split up into:
* Hardware driver for sending raw data to and from the hardware
* Protocol driver for translating the codes from the controller app to codes the hardware can understand (both ways)

On Linux there exists a system for hardware drivers, which is a kernel driver with a common interface to the controller software that is independent of which hardware you choose to use. This is called DMX4Linux.

For various reasons there is as many separate drivers as there is in DMX4Linux.

Most USB interfaces works as a "virtual com port", which means that there is a real com port in the hardware, and a driver makes a com interface available i the operating system. Most USB com ports are supported 'out of the box' on both Windows and Linux (nice!), so most USB-to-DMX interfaces just need a protocol driver (easy to make and use)

On Windows it seems that (almost) all controller apps have their own drivers.

Remember that it is possible to send DMX data over a network to an other computer or an Ethernet-to-DMX hardware interface

If your are looking for a interface to buy, then start with finding your favorite controller app, and find out which drivers and thereby which hardware is supported.