Personal tools
The Open Lighting Project has moved!

We've launched our new site at www.openlighting.org. This wiki will remain and be updated with more technical information.

Difference between revisions of "OLA developer info"

From wiki.openlighting.org

Jump to: navigation, search
Line 43: Line 43:
  
 
Suggestions for content:
 
Suggestions for content:
 +
* What is the structure of the plugins?
 +
 +
This is the general lifecycle of a plugin:
 +
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?
 +
 +
 
* 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
 
* 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
* What is the structure of the plugins?
 
 
* What is the interface between the LLA core and LLA plugins?
 
* What is the interface between the LLA core and LLA plugins?
 
* What is the interface between the LLA core and other apps/clients to LLA like QLC?
 
* What is the interface between the LLA core and other apps/clients to LLA like QLC?

Revision as of 09:05, 13 November 2008

Or LLA code documentation Link to the 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:

Driver Linux Mac OS X Windows
ArtNet Linux=Yes  ??  ??
ShowNet Linux=Yes  ??  ??
ESP Net Linux=Yes  ??  ??
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
Pathport Linux=in testing  ?? No
E1.31 / ACN Linux=development started  ?? No

Note 1): Support through the Linux kernel module from Erwin Rol, as detailed in LLA, OpenDMX USB and Q Light Controller Tutorial.

Unsupported USB devices:


Suggestions for content:

  • What is the structure of the plugins?

This is the general lifecycle of a plugin:

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?


  • 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
  • What is the interface between the LLA core and LLA plugins?
  • What is the interface between the LLA core and other apps/clients to LLA like QLC?
  • What is it with the hidden web server?

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

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 :-)

LLA plugin for the "USB Pro"

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