Cuelist Property editing



With LAS V7.0 a new e:script command was introduced: CuelistSetProperty(). Now what is the point for you? You can save a lot of programming time by setting a Cuelist Property (say SpeedMaster) for many cuelists in one go.

“What does that help me – I’m no scripting guy!” Well, just import the attached macro and the Action Pad page into your own show. You’ll get an Action Pad page that allows you to alter a Cuelist Property of numerous cuelists with just a few clicks.

Just click the image to download the macro and the Action Pad page!

Sending RDM commands via e:script

This script shows how to reset a device via RDM to factory settings. All you have to know is the RDM address of the device, you don’t have to know the port or controller to which the device is connected, as the the reset command is sent via all ports that support RDM. And you don’t have to activate RDM. This is an easy and simple way to reset a device without a former RDM discovery. Even devices not answering to discovery requests can be reset. This is the procedure:

After declaring and initialising the necessary variables, an iteration run is executes over all controllers and corresponding ports. This includes ports that have no activated RDM. The key function here is SendRdmRequestByController.

// RDM reset script by Till Wiebke
// Traxon Technologies Europe, Paderborn
int controller = 0;
int port = 0;
int success = 0;

// Unique RDM ID of the target device.
string target = "4845:000002C6";
// The binary object block is needed for the custom RDM request.
int bobHandle = BobAllocate(0);

for (controller = 0; controller < GetRdmControllerCount(); 
   for (port = 0; 
        port < GetRdmControllerPortCountByController(controller);
      // Enable the controller if necessary.
      success = RdmPortIsEnabledByController(controller, port);
      if (0 == success)
         success = RdmPortEnableByController(controller, port);
      if (1 == success)
         // Sending a "factory reset" (0x0090) 
         // set-request (0x30) to the root-device (0).
         printf("FACTORY_DEFAULTS to %s, controller %d,port %d.\n",
                                         target, controller, port);
         SendRdmRequestByController(controller, port, target, 
                                    0, 0x30, 0x0090, 0, bobHandle);

Available for download:
Lighting Application Suite 6.1

Since end of July 2013 available for download: version 6.1 of our Lighting Application Suite. Here is the link.

RDM Autotext in Action Pad

RDM Autotext in Action Pad

One of the main changes is the reworked RDM (Remote Devive Management) subsystem allowing more RDM, not only from e:sscript, but also as Autotext. Use RDM in the Action Pad, use e:script to automate RDM logging or watching. More info? Use the System Manual and Advanced System Manual for the LAS, also available for free download.


Various new RDM commands like GetRdmControllerCount, RdmDriverHasRdmSupport,
RdmPortEnableByController, SendRdmRequestByController, GetRdmResponseCodeDescription, GetRdmSubDeviceCount, GetRdmSubDeviceID etc. See the e:script Reference in the Programmer for details.

There is a new event, RDMEvent, that can be registered. More about events and RDM in the Advanced System Manual.


There are several new Autotext functions for RDM. See the chapter about Autotext and the Action Pad for in the System Manual for details. See also the post about RDM Autotext below.

Device Manager

LCE2 Devices

LCE2 Devices

The Butler PRO is supported as DMX output device. The LCE2 I/O Interface is available as DMX/RDM input and output  and as terminal driver. Butler XT2, XT, S2 and PRO have a new RDM Discovery Mode definition. Discovery mode can now be defined as complete, discovery or off.

Blackmagic Intensity Pro (LCE2-fx)

In order to support the capture card Blackmagic Intensity Pro in the LCE2-fx the capture dialog in the Media Player was extended. For every capture device in the dialog the resolution in Hertz is now displayed as well.

Update Dialog

The Update Dialog is now just a topmost window and the Programmer will start as usual with the Update Dialog shown on the top.

MIDI Learn for Triggers

MIDI Learn for Triggers

Trigger Rule Dialog

The Trigger Rule Dialog has a new MIDI Learn button. When the button is pressed, the next MIDI input will be used to configure the trigger rule.

Cuelist Actions

Two new options to the Cuelist Actions have been added: Skip Forward and Skip Backward. The actions behave exactly like the Skip Forward and Skip Backward buttons in the Cuelist Dialog.

Show Export

The show export log view shows now, which triggers where exported and which could not be exported.

Versatile Masters setup

MIDI Learn for Masters

MIDI Learn for Masters

The Versatile Master configuration dialog now has a MIDI Learn button. The MIDI Learn button will only listen to MIDI control change input (cannot be added to a fader).


LCE2 Page Setup

You can create individual display pages for the LCE2 display. Actions can be connected to every display page. They are available in the “* Custom Menu *” by default. See the chapter Settings for details.

RDM with Butler XT2, XT, S2 and PRO

There is a new RDM Discovery Mode definition available. Discovery mode can now be defined as complete, discovery or off. Complete is the default mode in which all RDM devices are discovered and all RDM parameters and sensors are polled. Discovery means, that the devices are only discovered. So only their RDM unique ID will appear in the RDM Browser. Off means, that RDM communication is enabled if the port is enabled but no discovery communication will be performed. You can sent custom RDM requests per e:script in this mode.

Sequencer properties

The Sequence Properties dialog has two options now to adjust the amber/white level for

Persistent data in the Programmer

When running in User and respectively in Kiosk Mode, an e:cue Programmer show is considered as persistent with unchangeable data. This is for safety reasons, in case that you want to grant users limited control over a lighting installation (in most cases via the Action Pad) but nothing more than that. Nevertheless, there might be the need to save some status information even in User/Kiosk Mode. As an example you control several rooms using Action Pad faders and you want the lighting values to persist after system shutdown/reboot without making changes to the show file itself.

The e:script language features a set of commands to write variables into an XML file for later use. First, you have to use XmlBegin to specify a filename and if you want to read from or write into the particular file. The next step is to use the command XmlExchange to read/write certain variables (this depends on what you specified with XmlBegin). To close the file operation, call XmlEnd. You can use XmlExchange multiple times inside such an XmlBegin-/XmlEnd block to read or write multiple variables from or into one file.
Please note that a write operation will completely erase the previous contents of the given file. So be careful to use the correct filename. If no file with the given name exists, a new file will be created.

As a filename, you can either specify a simple filename (in that case the file will take its place in the Programmer’s main directory) or a complete path along with the name of the file. To use the My Documents folder of the current Windows user you can write $(MyFiles) followed by subfolders and the filename. When specifying a complete path, you must not use single backslashes as a separator because these are interpreted as control characters. You can either use a double backslash or a single slash as a separator.

Masters as XML

Masters as XML

Fader values exist in the file and of course, are already declared inside the macro. In the special case when you read out an array, the array that was declared has also to be of exactly the same size as the array that was saved into the file before.

When you write a variable into a file, the particular variable must exist, of course. The command XmlEnd finishes a read/write operation. Please note that a write operation will only occur when you use XmlEnd.

When saving masters as values, 4096 relates to 100% and indices of masters begin with 0.

Example: Saving and recalling fader values

To save the position of Action Pad faders we have to query the status of the associated Versatile Masters and save the particular values into a file.

Assume that for our purpose it is sufficient to save the values of the first 12 Versatile Masters. The corresponding code is very short and easy:

int vmaster[12];
int i;
for (i = 0; i < 12; i++)
   vmaster[i] = GetSpeedMaster(i);
XmlBegin(“$(myfiles)\\vmasters.xml”, 1);

As you can see, an array named vmaster is declared in order to hold the values of the Versatile Masters. The values are received using the command GetSpeedMaster inside a for loop. The contents of our array are then all together written into the file vmasters.xml inside the current users My Documents directory. What we have to do now is to write a macro that restores the Fader values from the XML file. This is quite as easy and looks very similar to our previous code snippet:

int vmaster[12];
int i;
XmlBegin(“$(myfiles)/vmasters.xml”, 0);
for (i = 0; i < 12; i++)
   SetSpeedMaster(i, vmaster[i]);

We first read out the contents of our XML file (note the 0 as parameter for XmlBegin) into the array. These values are then applied to the particular Versatile Masters using the command SetSpeedMaster.

Using a function for complex data exchange

For simple variable storage and restore operations involving only a few variables, the example above works just fine. However, if you want to exchange a big set of variables, maybe even several times, it comes in very handy to write a function for the data exchange operation. This simplifies the code and prevents errors like forgetting a variable in an exchange operation as well. The following macro code shows an example function exchanging some sample variables:

function DataExchange(int do_save)
   XmlBegin(“vars.xml”, do_save);

The above function DataExchange has one parameter named do_save. This parameter specifies if you want to save or load the particular variables. As for both kinds of operation the same function is used, it can never occur that a variable is forgotten. To save the set of variables specified inside the function, call the function as follows:


To restore a set of saved variables, write:


Email for you

Since early versions of the LAS it is possible to send email via e:script. Up to version 6.0 this email distribution was handled with an e:cue server as gateway. From LAS 6.0 SR1 on a direct SMTP interface is available to send mail. Sending an email is helpful when systems run unattended or headless, so there is no way to alert somebody if something strange is going on. You could, for example, combine the script for RDM checking with this  email function to notify somebody about problems with some fixtures.

In any case you need access to an SMTP server as a MTA.

Programmer SMTP configuration

Programmer SMTP configuration

First of all  set the necessary parameters in the Application Options of the Programmer:

  • Name: Set the sender’s name for the FROM field.
  • Email address: The sender’s email address, the FROM address.
  • Server name: The address of the SMTP server
  • Port: The mail port of the server, depends on connection type and is set to values when the connection type is defined. Most servers accept  port 25 („smtp“), newer servers also port 587.
  • Connection security: The security type of the connection. If only notifying about something basic connection security should do.
  • Authentication method: The encryption level for the connection.
  • User name: The user name used to login to the SMTP server.
  • Password: The password for the SMTP server login.

After configuring your SMTP connection you can send email from e:script:

// Generate mail content
int hMailObject = CreateMail(“”, 
          “Hello World!”, 
          “The quick brown fox jumps over the lazy dog.”);
AddMailTo(hMailObject, “”);
// Schedule mail and remember the message queue ID
int nMessageQueueID = SendMail(hMailObject);
// Wait for message being processed
RegisterEvent(Frame, OnFrame);

function OnFrame()
   if (MailIsValidID(nMessageQueueID) == 0)
      alert(Unknown mail ID!\n”);
      exit; // shutdown suspended macro event
   // Is message being processed?
   if (MailIsProcessed(nMessageQueueID) == 0)
      printf(“Waiting for message being processed ... \n”);
      printf(“Message was processed.\n”);
      // Is a response available?
      if (MailIsResponseAvailable(nMessageQueueID))
         // Check if sending was successful
         if (MailIsTransmissionSuccessful(nMessageQueueID) == 1)
            printf(“Sending mail successful.\n”);
            alert(“Sending message failed!\n”);
      exit; // Shutdown suspended macro event

Reading RDM with e:script

RDM (Remote Device Management) is a remote management protocol on top of DMX and allows bidirectional communication with fixtures. You can read system values and status, and depending on the type of fixture you can set DMX addresses and other parameters. The Programmer of the Lighting Application Suite has a complete implementation of ANSI E1.20, Remote Device Management on board. With the coming LAS 6.1 you can read RDM values in fixtures and use them as Autotext (similar to time, astronomical times, system parameters) in the Action Pad.

You can also use the RDM API in the Programmer in e:script, which allows very flexible and custom-specific functions. Here is an example script how the RDM API can be used to check fixture temperatures.

// --------------------------------
// checkTemperature script comment
// --------------------------------

int sensorId = 7; // id of temperature sensor
int temperatureMax = 80000; 
              // commonly given in m°C so 80000 is 80°C
string deviceId;
int li = CreateRdmDeviceList();
int deviceCount = GetRdmDeviceCount(li);

// iterate all rdm devices
int i;
for (i = 0; i < deviceCount; i++)
     deviceId = GetRdmDeviceId(li, i);
     printf("deviceId = %s\n", deviceId);

// checks if temperature value from sensor 
// is within allowed range
function checkTemperature(string deviceId)
     int t = GetRdmSensorValue(deviceId, sensorId);
     printf(" %s %d\n", deviceId, t);
     if (t > temperatureMax)
          // do something if temperature too high
          alert("Warning: temperature of device %s is > %d!\n", 
                                   deviceId, temperatureMax);

Code examples from the Advanced System Manual



The e:script coding examples from the Advanced System Manual für the Lighting Application Suite cannot be copied via Copy/Paste from a PDF file. PDF files are coded in UTF-8 code format, while the macro editor of the Programmer only understands ASCII. For this reason we have made the files available as standard text files with a .cpp extension here: | Downloads | e:cue Software | Support Files

Programmer > e:script Macro Editor > keyboard shortcuts

For an internal training, I was writing down a few keyboard shortcuts for the Macro Editor.
I wondered if there are more and remembered that the Scintilla engine was used. Searching the web led me to which shows all possible keyboard shortcuts.

Here’s a list of those available and useful in the Macro Editor – enjoy   ; )

Magnify text size. Ctrl+Keypad+
Reduce text size. Ctrl+Keypad-
Restore text size to normal. Ctrl+Keypad/
Indent block. Tab
Dedent block. Shift+Tab
Delete to start of word. Ctrl+BackSpace
Delete to end of word. Ctrl+Delete
Delete to start of line. Ctrl+Shift+BackSpace
Delete to end of line. Ctrl+Shift+Delete
Go to start of document. Ctrl+Home
Extend selection to start of document. Ctrl+Shift+Home
Go to end of document. Ctrl+End
Extend selection to end of document. Ctrl+Shift+End
Scroll up. Ctrl+Up
Scroll down. Ctrl+Down
Line cut. Ctrl+L
Line copy. Ctrl+Shift+T
Line delete. Ctrl+Shift+L
Line transpose with previous. Ctrl+T
Selection duplicate. Ctrl+D
Previous word. Shift extends selection. Ctrl+Left
Next word. Shift extends selection. Ctrl+Right