Events
Most programming courses start out with a “Hello World!” example. We’ve never been afraid of breaking the mold here at Alcorn McBride in service of doing things properly. That said, it’s time to start making some fun stuff happen. We’ve been through devices, sequences, triggers and we’ve seen events happening, but we haven’t looked at why or how. IT IS TIME.
Events are the Winscript way of saying “do something” to a device. That could do a calculation, do some logic, or take some action that will be visible or audible to a user or guest.
Events can be simple things like “Turn on LCD screen” or “Turn off the projector.” They can also be as complex as do a logarithmic crossfade from one track to another while calculating the log manually yourself.
Most events are instructions built specifically into a product file for a device that works specifically for that type of device. Items like power on, power off, mute, open/close shutter, change inputs, switch sources, run cue, playback video, etc. require a specific command to be sent that is different from device to device. Mute on one brand of devices might be the word mute, on another it’s MT, on still another it’s vol=0. Getting to know your devices and their available events built into the product file is immensely useful. We’re going to start with looking at the events that exist for the show controllers because that gives us an excellent foundation for how events work and how much we can do with “just” the controller.
There are two ways to enter events in WinScript – you can type them in directly in the Grid View OR you can add them using the Wizard. Just like with sequences, I can start the wizard by using the buttons along the top or by double-clicking on the row number on the left. If I double-click on the last row in the grid, I create a new event and start editing it just as if I’d hit the new button.
We’ll start out in Grid View, which is the faster of the two methods way to enter events if you’re familiar with what events exist. We can start out by scrolling the list of available events. There are too many of these to go through each one individually, so we’re going to pick out some key types, but you can look at the manual for your controller to get more details on an individual command – and if you’re having trouble with one, just reach out and we’ll give you a hand.
We’re going to start by building a simple sequence that we can run that uses some of these events and we’ll get into many of the other events in future videos and labs.
Delay
Display
Get Random
Off
On
We’re going to put on a little show – one that you’ve already seen the results of in a previous video. We’re going to make it RAIN (actually, we’re going to make it snow. But you could do rain or sleet or a lot of other fun things when you get to the lab!). And we’re going to put on a little light show, too. I’ll be working in Live Mode, where I’ll be connected to the controller the whole time we’re working on the script. Ordinarily, you’d write the script offline and then connect to the controller and test it, but there are times it’s helpful to be connected to make quick adjustments while programming (during commissioning, test and adjust, creative updates, etc.).
Let’s start with the light show. All we’re going to do is turn on and off the outputs on the V16X in rapid succession. You can use any pattern you like. I’m going to do one reminiscent of a great 1980’s TV show. You can just imagine the whooshing sound as it plays!
First, we put in a time we want this first event to happen. The timecode is displayed in Hours:Minutes:Seconds:Frames. Frames are defined as portions of seconds. The default number of frames per second on the show controllers is 30 (based on video standards). You can also choose other frame rates as we learned in the lesson on Device Configuration.
We’re going to want this light show to move pretty quickly, so let’s put this first even at 2 frames, which is 1/15 of a second. We’re going to turn on output1. To do that, we choose the “ON” event from the Event dropdown. Notice that I skipped over the Device column. If you don’t choose a device, the controller assumes that you mean for that to be executed on the show controller itself, so that’s where it’ll happen. We could also choose to fill it in and be explicit with our command if we so preferred. Now that I’ve chosen ON, Param1 needs to be filled in with which output I want to control. Notice that the drop-down menu for it is context-sensitive – it will only allow me to turn ON things that are turn-on-able. This includes Boolean variables (setting the value to 1) or actual I/O device outputs on the controller or external I/O devices like the AMIO. So now I have this one event line that when this sequence reaches Frame 2 after starting will turn on this Output. Neat. Let’s make it do more!
2 frames later, let’s turn on output2 and turn off output1 at the same time. Notice that instead of choosing ON from the Event column drop-down, I’m choosing OFF instead. I still see the same list of possibilities in the Param1 field because they are the same type of command, just going to the inverse state. This will make it look like output2’s light is chasing output1. If there were devices attached to the actual outputs, they would mirror the behavior. We’ll repeat this every 2 frames through the magic of montage for all 16 outputs and when we get to the end, we’ll bounce and go back down to 1. Let’s see if we got it right. Cool – in 2 seconds, we went from output 1 to output16 and back. Let’s make it just keep doing that. We’ll set it to loop in the Sequence grid – and we’ll push PLAY to start the sequence running. Now, we’ve got that familiar scanning look.
You can do similar things like creating a chase pattern, create an alternating blink pattern, etc. While it isn’t actually all that functional, it shows you how you can use simple commands to do something effective – and if you were controlling actual lights in a show sequence, this could actually be part of a pretty cool sequence (though you’d probably be using DMX to control them – want to know more about DMX? Check out Scott’s excellent tutorial on DMX and show control in our course catalog!).
In this example, we’re using the timing of the sequence to manage how quickly we ran these items. If we took the time values out and just ran the sequence as fast as it could go, it would look like this:
The processor is running through the lines SO FAST that we can’t actually even see the I/O turn on and off (and if we were controlling something in the real world, it likely wouldn’t have a chance to respond).
It’s easy to see why time is important for a sequence like this.
There are other ways to manage time other than using the time column, though, and to leverage the power of numbers to achieve a really cool effect. Let’s (PICARD VOICE) make it snow.
I’ve created a new sequence for us called “Make it Snow” (thank you, Jean Luc). Notice that this sequence’s columns look a little bit different – there’s no TIME column here. This sequence is one of the logical types, and it’s going to run as fast as we let it. We’ll see just how fast that is in a few minutes. To start off here, we’re going to need to understand the controller’s front panel display. The display is 12 characters tall by 44 characters wide. We’re going to use the asterisk * character to represent our SNOW, and we’re going to put it on a random point on the screen, then wait a random number of frames, then do it again.
I’ve created some variables that we’ll be using in this lesson that you won’t learn about until the next one; in this case snowRow, snowColumn for location on the screen and snowtimecode for how long to wait in frames. We’ll see how those variables work in the next lesson, but for now, they’re here for us to use.
For my event, I’m going to choose “Get Random”. Get Random requires a number of parameters, and I can’t always remember the order of them. Let’s jump into the Wizard mode to get some help.
This first screen lets me choose my Device and Event. If this was a Timed sequence, I’d also get to fill in a Time value here for when it will execute. It gives me some helpful descriptions about the Event I choose from the list and will often include comments from the product file creator for more arcane event types. If we click Next, we’re taken to the Event Data screen, which allows us to look at the parameters required. Notice they aren’t called Param1, Param2, etc. on this screen – they actually have names that help you understand. On the grid, they have to be generic to support the hundreds of different devices and event types, but here, we get some help from the software on making these things more user-friendly (particularly if your memory works like mine!).
In this case, we are going to store our new random number in a variable. For this first one, we’ll store a value in “snowRow” which is the column number for our random snowflake to go into. Because our display is 12 characters wide, our minimum is column 1 and our maximum is Column 12, so those will be the values we’ll use. When I click Finish, I’m taken back to the grid and the options I’ve selected in the Wizard are populated for me into the appropriate columns for my event. Neat!
For our snow to work, we also need to know where to put the snowflake on the Y axis, so we can draw inspiration and knowledge from the X event we just created. In fact, we can actually copy this event (using the buttons, mouse or keyboard shortcuts) and paste a copy of it into our sequence so that we have two identical events and then just modify the items we need to make our second event do the Y-axis random number generation. So we’ll change Param1 to be snowColumn, Param2 will remain the minimum (row 1) and Param3 will be the last row, row 44. So now, we’ll have two variables storing some random number for row and column of where to put our magical snowflake. It’s time to put that snowflake on the screen!
The Display event manages to put the text out to the screen for reporting on things like status, uptime, errors, animations, and more (depending on your level of ambition as the programmer and the needs of the project). Because this is a new event for us, we’ll start with the Wizard on our new blank row here and we’ll choose Display from the dropdown. When we click Next, we see the list of information the event needs to be useful. For now, we’re going to use the “No Variables” variation of the event. We are going to place a single asterisk in the display text, wrapped in double-quotes. If we don’t put quotes around it, the controller will assume we are looking to use a variable instead and will let us choose from the available string variables. We’re going to put this asterisk in row snowRow and column snowColumn which are the variables we stored our random numbers into.
In theory, that’s all we have to do. We can set this to Loop and let it run and it’ll go as fast as the processor allows it to go. It won’t fill the screen instantly because our random number generator isn’t keeping track of where it’s put each character, so sometimes it’ll put a character where there’s already one on the screen, so sometimes it just looks like it hasn’t done anything for a little while – but it’s still running super fast and putting up our little snowflakes.
This is cool – but it could be cooler. Adding in a little bit of random delay makes it feel more like real natural snowfall. We can use the same concepts we just applied and get a new random number of frames into a new variable called “snowTimecode”. I’m going to limit it to between 1 and 9 frames because I don’t want this to take forever (there’s always a danger the snow plow will come by!) but I do want it to be random enough that it feels more natural. So I click Finish – but how do I take that value and assign it to my Display command?
Trick question — I don’t! This sequence doesn’t have any timecodes, and you can’t use variables in the time column anyway (the whys and wherefores of that are subjects for excellent Tiki Teria conversation if you’re interested). But – I CAN add that to a Delay event, and pass in that variable, and delay before running the next loop. Let’s peek at the wizard just to see what the options are – I can either enter a time value OR I can choose from variables that are of the type “Timecode” and it will use that value when it runs.
So now I have 2 get random events that get the location of the snowflake, a display event that puts it up on the screen, another random event to get a random delay value, and the delay event to pause before restarting my loop. Looks good? Let’s give it a go.
Now that’s beautiful. A real natural snowfall – completely undisturbed by ….
And it’s gone. But at least I can find my car in the snow now (kidding – I live in Florida! We have no snow!).
So that’s a quick look at Events. You’ll be digging into Events yourself in the labs, and you’ll find that each device that you add gives you additional options for new types of Events. The great thing about the way these controllers are designed is that we (or You!) can add new Events anytime there’s a new type of device or new command on a device that needs to be supported. That flexibility is a hallmark of our approach to show control.
A few housekeeping notes about events:
1. Order matters! If you put a sequence at a time that occurs later before one that occurs earlier, they will not be executed in the order you expect. Like most computing devices, this one is very literal. It assumes that you meant to do that. This happens mostly during the onsite commissioning process when it becomes necessary to “tweak” a live show by a few seconds here or a few frames there – and you end up with something out of order because one event got adjusted a little bit – and then you end up cursing at the screen; nobody wins, so just be aware of it.
2. Comments are the great unused feature of WinScript – they are available on every sequence, every event, variable, device variable, input, output, and lots of other places. Using these will make your code much more troubleshooting friendly, particularly if it isn’t you maintaining it 10-15 years later (did we mention these devices tend to live a long life?)
3. Speaking of documentation, Labels are useful for documenting your code and managing Sequence execution, particularly with Logic and conditional statements.
4. There are often multiple “flavors” or Variations of an event command. As an example (and we’ll get more into Logic statements in a few lessons), the IF = event has multiple variations – one that requires an End If event to close the logical loop OR one that if the condition is evaluated to true, jumps to a Label later on down the line. The display event also has multiple variations – the one we used and a second one which allows you to substitute variables for placeholders in your onscreen text. More on that in one of the labs!
Next, we’re going to dig into Variables and Device Variables, then take a look at LOGIC which promises to be fascinating. See you soon!