In order to create a mutual include group just go to the properties dialog for each cuelist that you would like in the group (right click on the cuelist at the bottom of the screen and then click properties). On the bottom right you will see a section called “Group Memberships” with a “Mutual” option. Choose a number and select that same number for all of the cuelists you’d like in the group. When one cuelist in the group is playing and another one from the same group starts, the first cuelist will stop automatically using the release time defined in that list’s properties.

You can have as many mutual exclude groups as you’d like, but please note that one list cannot belong to more than one mutual exclude group. Also, by default the group is 0, which means that is not in any group and will act normally.

The trigger engine in the programmer is a great thing, but one of the shortcomings is that other than setting a date range, there is no way to dynamically enable or disable a trigger in response to changing conditions. I’m going to show you a way to use a little e:script magic to do just that.

Rather than having a trigger perform an action directly, we’ll have the trigger call an e:script macro, passing a trigger ID number as a parameter. The script will check whether the trigger is enabled currently, and run the action if it is enabled or ignore it if not. In order to keep track of multiple triggers, we’ll use a global array that allows us to track an arbitrary number of and also include a script that you can call to enable the triggers, and one to disable them.

So, on with the code:

// init.cpp
// Set up the variables

// Only create the globals if they aren't defined
// already
if (undefined(_init)){
	int _init;
	int _triggercount =5;
	int _enabled[_triggercount];

	// Default all triggers to enabled state
	for (int i=0; i<_triggercount; i++)
	{
		_enabled[i]=1;
	}
}

This is the first script you’ll need (name it init), which will create the global variables that holds the status of each trigger as well as one more to that determines how many triggers you want to use. You’ll want to change the value of _triggercount to the number of triggers you plan on tracking. This script should be run using the “On Initialization” trigger so that the variables are declared as soon as the programmer is ready to go. When doing your initial programming, you’ll want to run this once or the rest of the scripts won’t work properly.

// enabletrigger.cpp
// getarg(0) is the trigger to enable
// if -1 is passed to getarg(0), enable all triggers

int nTrigger = getarg(0);

if (nTrigger==-1)
{
	for (int i=0; i<_triggercount; i++){
		_enabled(i)==1;
	}
	printf("All triggers enabled\n");

}
else{
	_enabled[nTrigger]=1;
	printf("Trigger %d enabled\n", nTrigger);
}

The second script (name it enabletrigger) will allow you to enable any trigger number by passing it as the getarg(0) parameter. By passing a -1, enable all triggers that you are using. If you are using a call macro action you’ll want to use the following format for your macro name: “enabletrigger, x” where x is the value of the trigger you want to use. If you’re enabling it from e:script, you’ll use the following command:

Call("enabletrigger", x, 0, 0);

again, with x being the number of the trigger you want to enable.

// disabletrigger.cpp
// getarg(0) is the trigger to enable
// if -1 is passed to getarg(0), disable all triggers

int nTrigger = getarg(0);

if (nTrigger==-1)
{
	for (int i=0; i<_triggercount; i++){
		_enabled(i)==0;
	}
	printf("All triggers disabled\n");

}
else{
	_enabled[nTrigger]=0;
	printf("Trigger %d disabled\n", nTrigger);
}

The disabletrigger macro is essentially the same as the enabletrigger macro, but it disables one or all of the triggers by passing -1 or the trigger numbers to the getarg(0) parameter.

// runtrigger.cpp
// Run any trigger requested if enabled
// getarg(0) is the trigger to run

int nTrigger = getarg(0);

// only run the requested command if the trigger
// is enabled
if (_enabled[nTrigger]==1){
	printf("Running trigger %d\n", nTrigger);

	switch (nTrigger)
	{
	case 0:
		GotoCue(QL(1),Q(2),0);
		break;
	case 1:
		GotoCue(QL(2),Q(1),0);
		break;
	case 2:
		ReleaseAll();
		break;
               // Add more cases for each trigger action you want to perform
	}
}

else{
	printf("Trigger %d is not enabled\n", nTrigger);
}

Finally, we have the runtrigger script, which actually receives the triggers and runs the action code if they are enabled. It gets called the same way as the previous two scripts using “runtrigger, x” from an Trigger action or the equivalent ”call” command in e:script. It will test first if the trigger number is enabled. If it is, we go into a “switch” statement, which is essentially the same as if you did the following:

if (nTrigger == 1){
    ....
}
if (nTrigger == 2){
    ....
}
if (nTrigger == 3)
    ....
}
....

You’ll want to add a new case/break clause for each action you want to track and add the code that you want to run when that trigger is available in between case and break. Make sure to update the trigger count variable in the init script to match the number of triggers you are going to use. Also, note that the count is 0 based, so if you have 5 triggers, you will have triggers #0-4. You don’t have to use 0 if it is confusing to you, but you then need to add 1 to the number of triggers you’re using in the init script.

If you update the number of triggers in the init script after you’ve run that script the first time, you’ll need to hit the programmer reset button to reset all of the variables, as they cannot be redefined a second time once that script has already been run.

If it’s not already clear, once you have everything set up here, the number in the “case” statement is what defines your trigger number, so to disable the action code for case 3 in the runtrigger script, you’d use a Call Macro action with a name of “disabletrigger, 3″ (or it’s equivalent call statement in e:script) in the action that you’d want to disable the trigger. To run trigger 3, you’d add the trigger to programmer’s trigger list and for the action use “runtrigger, 3″.

Please post in the comments if something in here doesn’t make sense. Good luck!

Download

While the names and locations of the settings discussed will be different from one router to the next, virtually all wireless routers will have the same basic options to configure your network. I’ll be using screenshots from the administrative interface for the Linksys WRT54G router, as it is one of the most popular and well known wireless routers on the market. I will be breaking this article down into 3 segments to keep things as simple as possible:

1. Basic Setup
2. Configuring Network Options
3. Security

Please note that this article assumes a prior basic understanding of setting up a network for an e:cue system.

1) Basic Setup

If you are using your wireless router in a very small system setup, you likely won’t need anything other than your e:cue devices, your server, and some patch cables. You’ll just need to plug each of the devices  into one of the numbered ports on the router. If you are using a larger setup that requires a switch, use a patch cable to connect one of the numbered ports on the router to a port on the switch.

One of the most common mistakes when setting up a wireless network is to plug the Uplink Port (some companies label it as “Internet”) to either connect to a server or the switch. This port should only be used to patch to a router or modem that will be providing internet access. Everything else should be connected to a numbered port on the router.

Once you have your router connected, you’ll need to follow its instructions to get to the administrative interface of that particular model. In most cases it will be a web based interface that you will get to by going to an IP address such as http://192.168.1.1 or http://192.168.0.1 both of these are popular default IP addresses.

Once you have access to the administration interface, you’re set to move on to configuring the network options.

2) Network Configuration

The goal for configuring the router is to get the router and your computer all on the same network segment and to set up the DHCP to do the same. DHCP is the protocol that allows computers to obtain an IP address and other setting automatically upon connecting to a network. It is what is used by default for most consumer network interfaces. You can learn more about DHCP here.

As the butlers (and other e:cue hardware) need static IP addresses in order to ensure that the server is sending the correct data to the correct devices, they do not support DHCP. With some planning, however,  they can coexist peacefully on the same network as devices that do. I generally set my butlers as the low end of the network segment (192.168.123.1+), setting my servers at 192.168.123.101+ and then using the 192.168.123.200+ for my router as well as other devices (laptops, smart phones, tablets, etc) to connect with DHCP.

Log on to your router’s admin page, and you should see something similar to this:

• Change the Name of the router to whatever you wish (“SSID” for some manufacturers). This is the name that will be displayed by your operating system when listing available networks.
• Set the Local IP address (Called “Router IP” by some manufacturers) to 192.168.123.200
• Set the last digit of the “Starting IP Address” for the DHCP server to 192.168.123.201
• Save the changes (the router may need to be restarted at this time).
• You may also need to disconnect and then reconnect to the router so that it receives the new DHCP settings.

Once these changes are applied, you should be able to access your e:cue equipment without having to manually change your IP address in your windows settings. You should keep your production server as a static IP address though so that it’s address never changes, which can cause problems.

3) Security

There are two levels of security that you need to provide, or at least be aware of: First, you need to control who can connect to the router, and secondly you need to control who has access to the administrative interface for the router.

Controlling router access

If, for whatever reason, you wish to allow public access to this router, you do not need to enable the wireless security on the router. The merits and drawbacks of the different encryption schemes are not really within the scope of this article but you can read all about them here. I’ll recommend that you go with WPA encryption. You’ll need to go the the security settings for your router, set the security mode you wish to use and the access key (the password that you’ll need to enter in order to connect to the router).

Each router is different in terms of where the security settings are and what security modes they support. Check your model’s documentation to determine how to set up encryption.

Administrative Access

The final step is to set a new password to access the administrative interface. This is an often skipped, but crucial security step. Default router passwords are a well known and easy to exploit vulnerability. Again, consult your model’s manual to figure out exactly how to change the password for your router.

Once you’ve got your wireless network setup, make sure to check out the articles on Setting up a Remote Desktop Solution, Setting up the HTTP Server. Also, if you are using an android device. make sure to consider my e:cue Remote Terminal app.

The downside, as you already know if you are familiar with UDP, is that unlike TCP (which HTTP uses) is connectionless and there is no guarantee that the data is being received. While TCP connections return an error if the data is not properly received, according to the UDP protocol, the data is sent out and there is no built-in checks that anyone is even listening for it.

A good metaphor for a TCP connection is a phone call… you dial a number and you either have the conversation you expected to have or you gett an error (“This number has been disconnected”, “Sorry, wrong number”, etc) where as a UDP connection is more like a radio station. You broadcast your message, but even if no one is tuned into your station, there is no way to know inherently whether your message is received (although you could, say, ask for someone who is listening to call in and let you know they hear you.

Without further adeiu, here are instructions for the method I implemented… you can obviously adapt it to suite your situation, but this should be able to give you a foundation:

First, we need to set up a generic UDP server device in your show file, so

• Open the device manager by clicking .
• Add a new device by clicking .
• Select “Terminals and Miscellaneous > UDP Generic” and click ADD.
• In the configuration window, select the network adapter you’d like to bind to and an available port.
• Once you’ve chosen all the desired settings, click OK

You should now have a UDP device ready to go. Now we have to create an e:script macro, which we will name UDP. I’ll give you the code to copy and paste first, and explain afterward. If you need an intro/refresher on e:script, you can read this tutorial:

// udp script comment
RegisterEvent(UdpReceive, OnUdp)
int sendport = 9001;
int nLen;
int nPort;
string sIpAddress;
string command;
string param;
string msg;
int nHandle;
int inBob;
int outBob;
inBob = BobAllocate(1500);
outBob = BobAllocate(1500);
Suspend();

// Handles an incoming UDP packet
function OnUdp(int nDriverHandle)
{
	// Clear the UDP input block
	BobSetRange(inBob,0,1500,0);

		// Copy UDP backet into a Binary Object Block
		nLen = ReceiveFrom(nDriverHandle, inBob, sIpAddress, nPort);

		// Exit if the packet is empty
		if (nLen <= 0)
		{
			return;
		}

		// Parse out the 2 byte command and the parameter
		command = BobGetString(inBob, 0, 3);
		param = BobGetString(inBob, 2, 255-3);

		// Send an acknowladgement for a CHECK RESPONSE message
		if (strcmp("CS",command)==0)
		{
			msg = "ACK";
			sendMessage(nDriverHandle);
		}

		// Turn blind mode on or off
		if (strcmp("BL",command)==0)
		{
			SetSwitchState("blind", val(param));
		}

		// Play specified cuelist
		if (strcmp("PL",command)==0)
		{
			StartCuelist(QL(val(param)));
		}
}

// Send a UDP message to sIpAddress on sendport, message is msg
function sendMessage(int nHandle)
{
	BobSetRange(outBob,0,1500,0);
	BobSetString(outBob, 0,255, msg);
	SendTo(nHandle, outBob, strlen(msg), sIpAddress, sendport);

}

This script takes advantage of e:scripts ability to run the script in the background. The first thing you’ll notices is the “RegisterEvent” command, which tells the programmer to call a function called “OnUDP” every time a UDP packet is received. After that there is a list of variables that are created for later use. You’ll need to change the “sendport” variable to match the port number that your client is listening on.

After the variables are created, thee is a “Suspend” Command which works in conjunction with the “RegisterEvent” command. The “RegisterEvent” tells the software where to send information when a particular event happens, while the “Suspend” command tells the software that you have finished setting up all the variables and such that you need and that control can return back to normal until the registered event can take place.

Most programs use a size of 1500 bytes for the payload of a UDP packet, and this is what I used in my case. A BOB (binary object block) was created to hold the data from the packet after it is received. A BOB is simply a chunk of memory that is set aside for use in your script.  Each time a UDP packet is received, the BOB named inBob is cleared using the “BobSetRange” command to ensure that no data from the previous packet remains to taint this packet. After the BOB is cleared, the “ReceiveFrom” command is called, which reads the most recent UDP packet and places the data into “inBob”. It also sets the “sIpAddress” and “nPort” variables, corresponding to the IP address and Port of the sender. It also returns the length of the packet, which is useful information to know.

After checking to ensure that the packet is not empty, the packet gets broken into components: the “command”, which is a consists of a 2 byte ASCII code and the “parameter” (param). The command specifies the action being requested, and the parameter contains any information needed to execute that action (such as a cue number or cuelist number).  This is done using the “BobGetString” command.

After the packet is split up into the command and parameter, you simply use an “if” statement for each command you’re defining to see if that command has been sent, and then perform the specified action within the “if” statement’s code block. I left a few examples in the code. Parameters are always passed as ASCII, but the value of a number passed can be retrieved using the “val” statement, an example of which can be seen in the “BL” command which turns blind mode on or off. The client will send either “BL1″ or “BL0″, it reads BL as the command and then either 0 or 1 as the parameter. The parameter is converted to an integer and then used in the “SetSwitchState” e:script command, which sets the state of blind mode. The PL command uses the same logic,  but is used to play the cuelist specified in the parameter.

The last peice of the puzzle deals with the weakness that I talked about earlier. Since UDP doesn’t guarantee that there is anyone out there listening, I created a “heartbeat” system, in which the client can periodically send out a request for a response. In this case, the request comes in the form of a “CS” (check server”) command. When it is received it sends back a UDP packet containing the string “ACK” (acknowledge). This allows the client to ensure that the server is there to process its requests. This is a simple solution that still doesn’t guarantee any given packet was being received, but it provided enough security on the installation I designed this system for, which was running on a contained network with very little traffic. For higher reliability you could certainly design an algorithm that, for example, responds to every command with a check-sum that verifies that exactly the right command was received.

In order to start listening to for UDP packets the script must be started. You can do this manually while you are testing, but should be automated with an “On Initialization” trigger so that it starts as soon as the show file is loaded.

The script I’ve put on here is a pared down version of what was created for a specific situation. You may certainly use it as a base for your needs, but you should most certainly adapt it to suit the particular requirement you are using it for. Over a small local network this works great, but I would definitely recommend adding more error checking for larger networks or use over the internet.

1. Create a cue list with the chase steps you’d like to use.
2. Go into the cuelist properties by either right clicking on the cuestack and clicking “properties” in the main window or from within the cuelist window, click button that covers the width of the window under the list of cues.
3. Go to the “Extras” tab.
4. Change the type to any chase you like.
5. Set the default chase speed (optional).
6. Set the “chase crossfade” option (0% bumps from cue to cue, 100% is a smooth crossfade between cues with no wait time between).
7. Click “OK”
8. Repeatedly press the play button along with the music. After a few presses, the BPM speed will automatically update to match your speed.

• If you are using the butler XT with an e:bus device, you must have an external 24V power supply attached.
• If you are using non-Traxon fixtures you must have a power supply providing 12V-24V.
• If you are using Traxon fixtures, but you have a DMX booster, DMX splitter, or a any similar device between the butler xt and the first fixture, you must have an external power supply providing 12V-24V.
• If you are directly connecting Traxon fixtures but no e:bus device, you do not need an external power source. The fixtures will supply an appropriate amount of voltage back.
• If you are using Traxon fixtures and an e:bus device, you need to disable power input over the DMX line by flipping the switch located behind the RJ-45 DMX connector. Failing to do so will cause a conflict, causing  an e:bus power error and you won’t be able to use any e:bus devices connected to the butler xt.

Warning! – The following describes editing of the windows registry. If you follow the instructions on this page you will be fine, but please note that making changes in the registry can be a dangerous and has the ability to render your system inoperable in some cases.

Instructions

• Close Programmer
• Go to Start/Run or Press [Windows Key] + R
• Type in “regedit” and click OK.
• Navigate to “HKEY_CURRENT_USER\Software\ecue\e:cue Programmer V5.3\Options”
• Find the setting named “m_go.password_active” double click on it
• Change the value to 0 and click OK.
• Start the programmer back up.

Once you do this, programmer should automatically start in supervisor mode instead of user mode. The password is still there, it is just not being requested. Once you are done doing your editing, you can re-enable the default to supervisor mode.

This trick has saved me a few times, but please use it responsibly. If you are an end-user, the software was probably protected for a reason and you may cause problems without realizing it if you are not familiar with the show’s programming.

In your root directory, create a new text file (or open the existing file) that you have set as the default file in the HTTP server settings. In that file, paste the following:

<html>
	<head>
		<title>e:cue Action Pad Redirect</title>
	</head>
	<body>
		You are being redirected to the action pad. If you are
		not automatically directed, please click
		<a href="/ActionPad/ActionPad.html">here</a>

		<script type="text/javascript">
			<!--
			window.location = "/ActionPad/ActionPad.html";
			//-->
		</script>
	</body>
</html>

Save the file and then go to a web browser and simply type in the IP address of the HTTP server. you should automatically jump to the action pad page as soon as you type it in.

For those of you who aren’t familiar with what an HTTP server is, it is the type of server used for web pages. I’m not going to go in depth about what HTTP is or how it works. If you want an easy-to-read yet thorough explanation of the HTTP protocol, you can find one here.

OK, let’s get started. For this tutorial I will be using programmer V5.3. This is important because both the settings and the method for choosing those settings has changed dramatically from older versions of the programmer. Also, you will need to be running the programmer in Enterprise mode (with an Enterprise dongle) to be able to start the server.

First thing you need to do is go to your application options by clicking the icon and then click on the “HTTP Server” tab. You should now be able to see this.

Enabling the Server

The first thing you’ll want to do is set your network interface. If you click on the IP address next to the “Network Address” setting, you will see a button labeled “…”  Click this button and you’ll get a list of IP addresses available on your computer. Select the interface that you would like to use.

Why do I need to do this? Say you have a server running a bunch of butlers on their own network. You can hook up a secondary network interface on the server that connects to the internet, corporate network, wireless router, etc. which will allow you to communicate with the e:cue software via a secondary network.

The default port for an HTTP server is 80. When you go to a website such as http://ecue.com your web browser automatically knows that it should contact that server on port 80. In most cases you should leave this as is. If, for some reason, you wish to change from the default port (you are already running another web server, or you want to use an obscure port to make sure no one accidentally stumbles onto the web page, etc) you can change it to any other valid TCP port number. If you change the port number, then you need to specifically ask for that port within your browser. For example, let’s say that we changed it to 99 and your IP address is 192.168.1.5 You would need to use the address http://192.168.1.5:99/somepath in order to talk to the server.

Now that you have your IP address and port set, click on OK and go to the HTTP Server log tab on the main interface. If everything went well, you should see a message that says something like “Listening on 192.168.123.5:80″. If you see that, you can go ahead and move on to the next section.

If you see a error message that says something like “Error setting up listener thread! Port 80 may be unavailable!” then your socket 80 is already being used by another program. Most likely if there is already another HTTP server set up on your computer you’d know about it and you can either disable it, change it’s listening port, or change Programmer’s listening port. The major culprit for unintended open HTTP ports is Skype. By default Skype uses port 80 to listen for incoming connections. You can either completely shut down Skype or go to “Tools > Options > Advanced > Connection” and uncheck the “Use ports 80 and 443 as alternatives for incoming connections”. Once you’ve done this, go back to programmer and try again to see if it works.

If you don’t have Skype installed and you’re still having this error message, then you’ll have to hunt down what program is keeping the port open, which is a bit beyond the scope of this article, but I can pont you to this tool which will make hunting it down a lot easier.

Preparing for use

At this point, if you are planning to use the flash action pad, you should be set, you should be able to point any browser on the same network segement as the server to http://192.168.123.99/ActionPad/ActionPad.html (replace the IP address with the one you are using) and you should see the flash action pad load up. You’ll want to pay attention to the next part of the article though because you’ll be able to use it to create a shortcut later.

If you are going to be creating custom HTML files, you’ll need to set the home path for them. You’ll want to create a folder on your computer for these files to be stored. The default is C:\ServerRoot but you can set it to anything you like.

Next you’ll want to set the default document. The default document is the document that is sent from the server when you don’t ask for a specific file name. For example, when you go to http://ecue.com the server is going to see that you didn’t ask for a file name, so it will give you http://ecue.com/index.php. Most servers use index.htm, index.html, or default.htm as their default documents. You can change it to whatever you wish, but I would suggest leaving it as index.html to remain consistent with the defacto standard.

Once you have the home folder and default set as you wish, click on OK then create a text file in that folder with the name of your default file (such as c:\ServerRoot\index.html). In that test file simply type “test” and save it. Now, go to your browser and go to your ip address (ie http://192.168.123.55) don’t forget to add the port if you selected something other than 80.

If you see anything other than “test”, go through and make sure that your file and folder names match the settings you created. If you used notepad, make sure that the file actually got saved as a .html file instead of a .txt file, as in some circumstances it will add it automatically so that you end with a file named index.html.txt. You may have to enable viewing of hidden file extensions.

Once you get to this point, you are able to use the HTTP server as described in the System Basic Manal help file included with the software. I will also be doing another tutorial in the future that goes in depth on how to create web based interfaces that use the server.

Security

The largest advances in the newly revamped HTTP server are in security. You can now assign a username and password both to the html part of the server and to the flash action pad. To enable the use of this security feature, all you need to do is set the username and password that you want and it will automatically be enforced next time you try to use the server. Unfortunately you can only have one set of credentials with no way to serve different content based on who is logging in.

Finally we have the “Security Policies” options, which mainly have to do with scripting.

• e:script Execution – allows execution of e:script commands over the http server
• System Commands – allows external programs to be called, which can be dangerous especially if left open on the internet
• Show Modification – allows cues to be recorded, etc
• File Modification – allows commands that save to, create, or delete external files

You should only enable the options that you absolutely need, and be especially careful if the machine is accessible over the internet or any other network subject to unknown users.