Partitioning DMX Channels

In Architectural and “Architainment” installations, it’s often necessary to split systems up into areas where each has distinct and independent control. Additionally, it’s important that changes made in each area be prevented from changing light levels in any other area, regardless of program content.

Channel partitioning also helps by allowing re-use of recorded resources. If the system is properly partitioned, you can set up looks that encompass multiple areas, and you can play them back in different areas in different times – saving maintenance/paperwork hassles later on, and helping reduce the overall show file complexity.

So how do we ensure that our area divisions are respected when we’re running cues or setting levels manually or from Macros using CueScript commands?

Setting up zones on a CueServer is fairly straightforward, but by design, zones are intended for use with simple static presets and provide room combine functionality. As of CueServer Version 3.1.0, zones currently do not offer a means of creating a channel partitioning scheme for cue playback – you can’t combine Zones with cues to create automatic channel-based partitioning.

So how do we ensure that our zone divisions are respected when we’re running cues or setting levels manually or from Macros using CueScript commands?

The solution involves configuring playbacks to enforce our zone boundaries and create absolute channel partitions.

The Walkthrough

Follow along below, or jump ahead using the index below:



1: The System

First, let’s start with a theoretical “Performing Arts Center” system comprised of 4 areas:

Area 1: Lobby - 16 Dimmers at address 1.1
Area 2: House Lights - 64 Dimmers at address 1.17
Area 3: Work Lights - 16 Dimmers at address 1.81
Area 4: Building Exterior - 170 RGB Fixtures — roughly 1 DMX universe of devices – at address 2.1

Setting up

First, I set up a 2 Universe system, with 5 Playbacks:

Each of the first 4 playbacks will be responsible for a single area of control, and I’ve added an additional playback for use by the exterior feature. One of area 4’s playbacks will be for static looks, while the other will be used for streaming playback of moving effects. Note the mode setting on Playback 5 - I set the default mode to “Override” because I want streaming effect cues to completely override static scenes and cues running on Playback 4. This will ensure that on startup our playback behaves as intended.

Next, I Patched Universe 2 for or our exterior building feature as it isn’t patched by default:

The Playbacks

Now that we have our basic system set up, let’s start work on our solution.

For the purpose of testing our system partitioning methods, let's record a cue with all of our DMX channels in it:

Note the CueScript command to set all of our channels to 100%.

This cue will be useful for testing as it purposely sets channel values across all of our areas.


Now let’s take a look at our playbacks:

In CueServer Studio, an effort has been made to visually represent how playback data is processed.  If you look closely at the center of the “Playbacks” window, you’ll see arrow shapes that show that playbacks are processed in numerical order from top to bottom.  What that means is that playbacks at the bottom of the list have an implied higher priority than those higher up.  This means that playbacks later in the processing chain can override playbacks that came earlier, depending on their operating mode.  While for this system this is really only important for playbacks 4 and 5, in more complex systems can become very important to arrange playback usage according to how you want them to interact.  In our simple case, since we want playback 5 to overlay on top of, and override playback 4, we’ve put it last after playback 4. 

Playback of our resources is also dependent on playback operating mode, so for reference, here’s a quick description of CueServer 2’s playback modes:


Merge playbacks are combined using HTP (Highest Takes Precedence) with previously processed playbacks


These playbacks will override the previously processed playback with the value playing back.  A value of 0 in an Override playback will force the value to 0.


These playbacks act as a master over previously processed playbacks.  The previously processed playbacks are multiplied by the value in the playback. A value of 20% in this playback will result in values from previously processed playbacks being scaled to 20% of their value.


Pin mode limits the maximum value of all of the playbacks processed previously to the value currently set in the playback.


Mask acts like an inverted master for all previously processed playbacks.  The previously processed playbacks are multiplied by the value in the playback subtracted from 100%. A value of 20% in this playback will result in values from previously processed playbacks being scaled to 80% of their value.  Channels in Mask playbacks act like the inverted master on a 2-scene preset console.


For more information on  CueServer 2 Playback modes see:

What are the CueServer 2 Playback Modes?


Now that we know how playbacks are processed, we can now come up with solutions to our channel partitioning problem.

Partitioning Setup

Both of our solutions require creating a Global rule that is triggered at startup. This global rule will set up all of our playback modes and partitions each time the system boots. 

Here we’ve added a global rule that performs a script on startup:

Now that we have our global “Partition Playbacks” rule, we can now add some CueScript commands to achieve our partitioning.

Option 1: Park channels at 0

The CueScript “Park” command is used to lock channels to a specific value in a playback.  Any level setting within a playback will not change the values of any parked channels.  Values-driven from cues, presets, or even live CueScript will not be able to affect the output of the playback.

Since most of our playbacks are operating in “Merge” mode, a value of ‘0’ in any playback will have no effect on any subsequent processing. This is because with HTP merging any non-zero value from subsequent will naturally be higher than 0, and will become active in the final output.

In this option, we are parking any channels that are not used by a given area at 0.


This is the Script Editor containing our desired CueScript:

Let’s review the Cuescript.

First, we make sure all of our channels are at 0, and nothing is active or parked at a value in any of our playbacks:

playback 1>5 clear

Next, we set up the lobby:

playback 1 channel 1>16 ~ park


Note: Here we use a little CueScript trick --  the ‘~’ command.  This is the “invert selection” operator.  Using ~ we’ve created a very readable CueScript command that says – “in Playback 1, select 1 thru 16, then invert to select all channels EXCEPT 1 thru 16, and park them at their current value”.  This makes the CueScript’s intent clear and allows this script to continue to work, even if the total number of channels in the system changes.

Then we use the same trick to set up the house lights:

playback 2 channel 17>80 ~ park


Work Lights:

playback 3 channel 81>96 ~ park


And our 2 exterior feature playbacks:

playback 4 channel 513>1024 ~ park

playback 5 channel 513>1024 ~ park


Now we can click the “Test” button in the CueScript editor and see the results.

First look at the playbacks:

We see in the rightmost pane of each of our 5 playbacks that there’s now red text telling us that there are channels parked.  This is a good start!


Next, we look at the stage view:


In the default “Output” layer, nothing much changes.  But if we switch our layer to “Playback 1”:


We now see that there are a large number of RED channels – denoting that the channel is parked – and since there is no red value, we know they’re parked at 0.


The next test is to switch back to the Output layer, and see what happens when we run our “Everything at full” cue in playback 1 – remembering that cue 1 contains 1024 channels of ‘FL’ values:

Only channels 1>16 have been affected by Cue 1 in Playback 1.  So far so good.

Now let’s try the rest of our playbacks.


Playback 2:

Playback 3:

Playback 4:

Playback 5:

Everything’s looking good!  Parking all channels EXCEPT the channels for a given area within that area’s playback effectively protects us from inadvertently setting values in other areas – with one downside: Don’t EVER use the CLEAR command on a playback. This will undo all of the parking you did, and eliminate all of the partitionings. When working with Parked channels in a playback, be sure to use the RELEASE command instead of “CLEAR” as the clear command include parked channels.

Option 2: Disable channels

If you don’t want to worry about using Clear vs. Release as you program the system, an alternative to parking exists.

To demonstrate, we can duplicate our Global Rule by right-clicking the rule in the Global rules, and saving it as Global Rule 2:

I also renamed them descriptively.

I then edited the script to replace the “park” command with “disable”:

Now if we click the “Test” button and look at our Playback 1 layer in the Stage view:

We now see that instead of red channel numbers for the channels, we see them in a dark gray – denoting “disabled”.

And if we run our cue in each playback:

Same results.  But this is where things are a little easier:  We now can clear every playback without worrying that our partitioning is going to disappear:

Even after we issue “Playback 1>5 clear”, our disabled channels are still configured:

Have a Tip or Trick you would like to see? Let us know!

Channel partitioning for a given area is a must when programming complex architectural installations using a single CueServer.  CueServer contains 2 effective means of partitioning playbacks for these use cases: Parking at 0, or Disabling channels.  As a rule of thumb, I use channel parking in more dynamic situations, where at certain times parking is used to mask the playback of a given resource.  This dynamic partitioning can be driven from external events when necessary.

When permanent partitioning is needed a global rule with channel disable commands is much preferred, as it protects us from our future self and our habit of clearing playbacks.

If you want a copy of the show file used for this tech tip, or if you have any comments or questions, please reach out to

Note: this tech tip was built using CueServer 2 version 3.1.0 (June 2019) – and may not reflect functionality in the current release version.  Please reach out if you need an updated version of this tip!