Q-SYS Corner

[Steve Guttag]

Without removing the Core and opening it up, I don't know of a means to find out its RAM capacity. The serial number contains the week/year of the unit so determining 2017-APR is going to be easier to determine.

I just read in another forum that the RAM is indeed the stumbling block. This Crucial brand RAM kit has been tested (by users) to allow operating QDS10: crucial 8gb kit 2x4gb CT2K51264BF160B DDR3L - 1600 SODIMM 1.35V CL11. The noted that DDR3L is key. DDR3 did not work. I also hear that the 4GB kit also works (2 x 2GB). One would think that QSC would offer a RAM upgrade themselves as that would be a cheap/easy way to keep an existing system going. Then again, one would think that they would also offer the boards within a Core as a repair part as they are just screwed in. One can be in and out of a Core 110 in under an hour, regardless of what has failed.

I just had a Core 110c repaired...and by repaired, I mean they changed one of its boards and did indeed up the RAM in it. They also upped its storage too (which probably came along for the ride with the new CPU board). I would presume that it is now QDS 10 capable but since there is a TSC-7 in the system, that won't be happening. Then again, it should have been okay with QDS 10 since it was a 2019 unit.

[Steve Guttag]

Q-SYS For Cinema
Blog-16, QDS–Part-12, Sample 7.1 Part-11, Logic and Control Part-5

Current QDS Versions: 10.0.0 and 9.4.8 LTS.
Sample 7.1 design version: 4.3.0.0

Introduction

This blog will focus on the remaining control for the Sample 7.1 design. The next blogs should start the wrap up the Sample 7.1 design with a discussion of the UCI and duplicating an auditorium.

Disclaimer

If any of the content in this blog happens to show up in a Q-SYS exam, it is not my intention to provide an answer-sheet beyond the discussion of good practice. I have not seen any form of the cinema final exam (my Level-1 was before there was a cinema version).

Disclosure

I do not, in any way, work for QSC/Q-SYS. These thoughts are my own based on my own interactions with the product(s) and implementing Q-SYS within actual cinema environments. I do work for a dealer that has sold QSC products since the 1980s, including Q-SYS and its predecessors. For the purposes of this blog, I represent only myself and not my employer(s) or any other company. Control Components

So, picking up after the booth monitor, we have the four relays and Amp Power:

Blog16Image1.png

Relays

So, what are the relays? The DCIO-H has four genuine relays for controlling typical theatre things. For instance, they could be used to control a dimmer or a masking system. Because they are relays, they don’t have the restrictions/conditions of a typical GPO that might use an “open-collector” type transistor output (transistors are more delicate and, often, limited in the current capabilities. They also, often, have pull-up resistors that could interfere with what you are controlling). You should check the device you are wanting to control to ensure that you do not exceed the capabilities of the relays. They handle up to 30VDC at 1-amp and provide both Normally Open and Normally Closed contacts.

The Sample 7.1 Design has configured them to be pulsed relays but you can configure them anyway you choose. Let’s look at how they are configured.

The blue buttons in the image above sets off a sequence of events. If you want to trace how it is configured; how would we do that? Our friend <CTL-F>.

Blog16Image2.png

We can jump to the source of the control.

Blog16Image3.png

It is a “One-Shot” button within an LFO (Low Frequency Oscillator) that is inside a container labeled “Relay Pulse Buttons.” Wow…there is quite a bit going on there too! It looks more complicated than it really is.

The LFO is a handy component for making (among other things) a “pulse.” The one-shot feature of it (turn off “Free-Run”) allows one to send out a single pulse (low-to-high and high-to-low transition). They have it set to square wave, which may seem like a good choice but I’m guessing there is a test question in there. As such, I’ll work with it in its present form. Just know that a wave like a square wave has a positive going wave and a negative going wave for its complete cycle and we just want one of them. There might be a better choice that reduces our overhead. A clue would be the 3-second period when the pulse duration is just set to 1.5-seconds.

So, what does the LFO do in this design?

Blog16Image4.png

Hmm. It has a Signal Name of T1 that goes to “Period.” We’ll come back to that one. It has a Signal Name on its Output of RELAY1-A1. That shows up on the DCIO-H’s GPIO:

Blog16Image5.png

We were expecting that since it was called “RELAY 1.” If you open DCIO’s component up so you can see its buttons that represent the relays, you can emulate the design <F6>. Press the blue Relay 1 button (in the schematic) and watch the “Relay Output” “click” for the desired amount of time.

Blog16Image6.png

You can also verify that if you change the time (they labeled it as “width”) that it does indeed change to the desired pulse width.

Okay, what’s with all of the crazy extra components in there with “Relay Pulse Buttons” container?

Blog16Image7.png

Because the Square Waveform was chosen, we need to get the period to be double our desired pulse duration. They:

• Added a “Custom Control” (RSP component) and set it to be a “Float Knob” and then labeled it “Input.”
• Added another Float Knob and set its range to 2 for both minimum as well as maximum so it is always set to 2 (or 2.00, since it is a float knob).
• Added a “Control Function” (also a RSP component) and set it to “Value Product” with 2 inputs.

All of that allowed them to provide a means of setting the desired pulse duration and multiply it by 2 so that the LFO would time out properly. So, if you set the width to 1.00, the float knob will go to 1.00. It will be multiplied by 2 using the Value Product component and the result is sent to the Period of the LFO.

So, what are those “Width” controls?

Blog16Image8.png

They are the Float Knobs from the “Input” controls shown above. You can use <CTL-F> to find that out.

Blog16Image9.png

To get the float knobs into a desired form, merely drag the knob out of the Custom Control and change it to a “Text Field” in the properties of the knob you just drug out. Then size it and set the colors as desired.

Blog16Image10.png

[Blog 16, Page 1 of 4]

[Steve Guttag]

Amp Power

Compared to the Relays, Amp Power is going to be easy. Again, using <CTL-F> you can find that it is a Toggle Button (Custom Control).

Blog16Image11.png

The PWR-A1 Signal Name connects to the amplifier “Power On” pins.

Blog16Image12.png

So, there is nothing tricky there.

Test & Measurement

Pink Noise

In order to tune a theatre, we need to have a means of sending a known/calibrated pink noise source to the various channels. Q-SYS has a specific Pink Noise generator for cinema that has the prescribed 12dB crest factor pink noise and should be used for cinema calibration. And, furthermore, the reference level for cinema is -20dBFS. So, when you are calibrating your speakers to 85dBc-slow, your pink noise should be set to -20dB.

If you’ve been reading the blog, you will know where the pink noise generator is in this design. They chose to make the pink noise generator to be a source, just like DCPs, Mics Non-Sync. So, you’ll need to go back up to the upper-left of the design, where the other inputs reside.

Blog16Image13.png

For a quick refresher, I added a Snapshot Controller for just the level so we could return it back to -20dB quickly. I also brought out the level so, when we are setting up a system, for the first time, we can lower the level to say -40dB to better protect the speakers until we know things are hooked up correctly and we are in the right ballpark for out output levels.

The PINK-A1 Signal Name lands on the “Routing” on pin 24.

Blog16Image14.png

Okay, back to the Test & Measurement section:

Blog16Image15.png

Those magenta (you might even call them “pink”) buttons are Snapshot Load buttons and you can use <CTL-F> to find which buttons they map to. The Snapshot controller is right above the buttons.

Looking at the Snapshot section of the schematic (LSP) we can see what is involved on a Snapshot Load (what happens when you press one of the buttons?).

Blog16Image16.png

Note, they used “All Controls” for each of the three components they are controlling.

• For Routing, the Pink Noise input is selected and the outputs are muted, except for the channel or channels that are desired.
• The SURR OFFSET GAIN is returned to 0dB (so you set the surrounds to 82dBc for each of surround channels).
• Cinema Pink Noise Generator is set to -20dB.

So, when you select a channel, the Snapshot takes care of ensuring that internal gains are set to where you want them so you can just worry about setting the output levels.

I find it odd that the way they turn PINK OFF is to leave Pink Noise selected but MUTE all outputs (from the Router). The SURR OFFSET GAIN is set to -3dB. So, it does not leave you where you were. You need to reselect whatever format you want (i.e. FEATURE 7.1).

Since both the Format Selector and the Pink Noise control the Router, there is a Snapshot interaction. If you select a pink noise channel, the format button merely dims…so you don’t really know what format is selected.

This is what the UCI looks like when you conclude your pink noise usage (PINK OFF) if you were on Feature 7.1.

Blog16Image17.png

If there was no sound (and there won’t be) …the user won’t know that there is an internal pink noise selected and that it is off. In my opinion, that is a little sloppy. I’ll refer you back to Blog-10 for my opinions on how I would recommend injecting pink noise to avoid this sort of design pitfall.

Pink Noise Injector

Speaking of injecting, they provide an Injector (a couple really) but one is tied to the Cinema Pink Noise component.

Blog16Image18.png

This can be quite handy. With a live system, you can click on that Injector and move it to whatever pin in the signal chain you want to test and then hover your cursor over various outputs to trace out the signal path to look for breaks or other problems and, of course, you can listen/measure what is coming out of the speakers.

Some people do not even build in a full pink noise system and JUST use the Injector to put the pink noise where they want it. There is nothing wrong with that but it can be frustrating because one false “click” and the Injector goes running back to its parking spot.

As an example, if I wanted to inject pink noise into the Right Rear Surrounds (RRS), it would look like this:

Blog16Image19.png

Note, the injector has a gain associated with it…you might want to make sure it is set to 0dB, if you are calibrating anything off of it.

Blog16Image20.png

IO Monitor

The IO Monitor can be handy device. As its name implies, you can monitor the input and outputs. They have it connected to an RTA. In the Sample 7.1 Design, your input is the DCIO-H and your outputs are the amplifiers. You can select any channel on any of your input/output audio devices.

Blog16Image21.png

You could combine that with “hovermon” (where you can merely hover your mouse over an audio pin and hear the audio at that pin plus it provides a mini-RTA) to check your system.

[Blog-16, Page 2 of 4]

[Steve Guttag]

Signal Probe and Signal Injector

Blog16Image22.png

These are way-cool. If you’ve ever worked with a patch bay, that is what is like to work with the Signal Probe and Signal Injector. You can drop the Signal Probe wherever you want your source signal to be and then drop your injector wherever you want to inject that signal. You can, literally, rewire a system, on-the-fly with these.

I think they should be part of any “Test Kit” within a Q-SYS System. You get gain and mute with each of them too so they can be very handy when working with them as a pair.

You can certainly put multiple ones in your design, as this one has done. So, be sure to color coordinate them so you know which ones you are working with! Just know, they are temporary. If the system reboots or you close down your instance of QDS, they will snap back to their parking spots.

GPIO & Control

Blog16Image23.png

We’ve already covered just about everything in the first column (Fader Snapshot, Bypass Snapshot, and the Amplifier Power). If you plan to have a clock anywhere in your design. It can be used for UCI displays as well as other components where you might want a timestamp.

Blog16Image24.png

You do have a degree of customization on how it displays the date and time, which can be particularly useful as different parts of the world display dates differently and you may prefer 24-hour time versus 12-hour.

The time is whatever the Core’s time is. That is how you set it. Set the Core’s time in Core Manager or via NTP (configured in Core Manager).

GPIO In (and out)

Blog16Image25.png

You should note that the GPIO In is from the Core, not the DCIO. Different Cores have different GPIO capabilities. The Sample Core is a Core 110f.

We are using just GPIO-1 as a contact closure input:

Blog16Image26.png

So, when input 1 is connected to the Core’s GPIO Ground terminal, it will be “On” or “Active.” Typically, a mechanical switch or relay is what one would connect here. In the case of this design, we are wanting the Fire Alarm system to provide a dry contact closure (relay) input when the Fire Alarm is active. Normally, they can provide either Normally Open (what we want, in this case) or Normally Closed relay contacts. If they can only provide Normally Closed contacts (open when there is a fire), then we would need to put a “Logic NOT” (Control Function) on our GPIO pin.

After the GPIO, there is a Toggle Button and they brought that out and placed it right below the component. Why? So, you can test the system without needing to either unwire it or set off the fire alarm. You will want to know that when you press the “FIRE” button that the system behaves as expected. You would NOT want to put that button on the UCI! (why not?)

The output of that toggle button is connected to the “System Mute” (RSP component) and it has a FIRE1 Signal Name.

The System Mute does as you would think, it mutes all outputs during a fire event. It unmutes to -20dB and then ramps the level back up to 0dB. That is, when it is muted, all outputs are muted but when it unmutes, it applies a -20dB to all outputs (on top of what you have already set them to) and then ramps them back up to “normal” levels so all of your calibrations are at the same levels as they were.

Just know, the System Mute does not go out of its way to call attention to itself. In the upper-right corner of QDS, there is a “speaker” icon that will either be red with a slash through it (muted):

Blog16Image27.png

Or black, without the slash:

Blog16Image28.png

You probably will want it to be obvious that the system is muted (appropriate LEDs located in the UCI and possibly the schematic).

You are free to use other means to kill the audio/show during a fire event. For example, you could put the amplifiers into Standby as that would also indicate that the system is not playing audio (the CX-Q amps will have their buttons turn red). Your Amp Power button would also turn red. There is the Mute button on the DCIO could also be utilized…again, that will show to the user that the system is muted.

Okay, let’s not forget that “FIRE1” Signal Name. Where does it go? It goes to the “Logic Or” (Control Function). The OR is if either the FIRE1 or the DCIO MUTE-A1 are activated, the MASTER MUTE-A1 is activated.

So, where does the MASTER MUTE-A1 go? <CTL-F> and we find that it goes to the Classic Cinema Fader if you made the changes I made back in Blog-14 or the “MASTER FADER” if you retained the original dB-based fader.

Blog16Image29.png

But notice that Muting the Master Fader/Classic Cinema Fader also mutes the DCIO-H’s Mute button, which gives the user a means of indication that the system is muted. This is good. But there are some not-so-good aspects.

• If the user presses the DCIO’s MUTE button, in this condition, what happens? The DCIO Mute LED goes out but the system remains muted. That could lead to a frustration of the system not properly representing the state that it is in. Remember, the Logic-OR needs either the FIRE1 or the DCIO MUTE-A1 to remain active and so long as the Fire event remains active, the system is muted.
• When the Fire event is over, the mute button and Master Fader remain muted. But they can be unmuted, at that point, by pressing the DCIO-H Mute button, a UCI control or automation/server cue.

Speaking of UCI controls. Can the user unmute the system from there? No. The System Mute is muting all of the outputs. Furthermore, so long as the DCIO-H is Muted, the UCI Master Mute button will fight you to stay muted. Now, if you wanted, you could take something like the LFO and set up a system that, so long as there is a Fire event, there would be the LFO perpetually pressing MUTE to ensure people could not override the system but, by and large, this is probably excessive. You just want to ensure that you are compliant with any fire codes applicable to your site. You also want to provide enough information to your users as to the state of the system.

[Blog-16, Page 3 of 4]

[Steve Guttag]

Automation Command List (ECP)

The Automation Command List is a Popup Button (RSP Component) and is a handy command structure for those using the “ECP” commands. ECP commands are going to be the most popular for cinema since cinema servers and automation systems can send them. They are Ethernet commands using TCP port 1702.

Blog16Image30.png

I suppose I should add in my linear Fader command:

Blog16Image31.png

I opted to use the “csv” (Control Set Value) instead of “css” (Control Set String). In this case, either the GAIN or FADER, both can be represented as Strings or Values so either can be used. But, since all of the other commands are “csv,” I didn’t see the point of having one oddball command.

The ECP commands can be found in the Help file here (note, this link will need to change for the version of QDS you are using):

https://help.qsys.com/q-sys_9.13/#Ex...P_Commands.htm?

QSC has a couple of training videos in their Quick Starts that discuss ECP commands in more detail.

Part A: Connecting to Q-SYS
Part B: Issuing Controls

There is a Part C for Change Groups but I think that is beyond typical cinema needs.

Now, if you are going to use one Core for multiple screens, it is imperative that you think about your “Named Controls” to also specify the theatre you are controlling. There will be just one IP address for your servers/automations to talk to. So, your commands must be unique for each theatre (e.g. FADER-A1 would be a better choice if there are multiple screens).

Blog16Image32.png

And don’t forget to fix the “Automation Command List”

Blog16Image33.png

It should be noted, the ECP control systems will shut the TCP socket down after a minute of inactivity. What this means is, depending on what you are using to control it, you may need to allow for opening the socket before issuing your desired command. Or you may need to configure a “keep alive” routine that polls the Core every 50-seconds or so. A common command to use for this is “sg” for Status Get.

You can use “sg” to open the port and then issue your command too. So, you could create a command like: sg\x0A csv F71-A1 1\x0A (select Feature 7.1).

Note, I used \x0A where you could use whatever your device uses for “new line.” Often that is the shorthand of \n

When working with Doremi products and their Dolby IMS descendants, you will want to bookend your command with a \w (wait command). So, if using, for example, the IMS3000, let your command be \Wcsv F71-A1\n\w. Q-SYS would also respond if you threw in a carriage return (it will ignore the carriage return and still process the command). So, \Wcsv F71-A1\r\n\w will process the same as without the carriage return <\r>. I’ve used the capitol \W on the leading part of the command to give a slightly longer wait. It should work with either the capitol or lower-case “w.”

Conclusions
The control system is reasonably straight forward, in my opinion. Probably the trickiest part is making the relays “pulse” type relays but rest is really pretty straight forward. The probe and injector are very handy tools as is “Hover Mon.”

Hover Mon Help

This is not an all-inclusive design but it is one you can build (and learn) from. I have made some suggestions and critiques (along the way in most/all of the blogs) but those positions are my own and not, necessarily, definitive. Q-SYS is a very flexible platform and able to embrace all kinds of design philosophies as well as accommodate more than most any other cinema sound (and control, with video to boot). My changes should highlight just how easy it is to make the design your own. It is just a few clicks and drags away.

The control system can integrate with your existing servers/automations just like with other sound systems.

Well, this has been quite a journey. This is the last part of the schematic portion of Sample 7.1 Design. The next blog should be a look at the UCI. We’ve touched on it a bit throughout the discussion but there are some bits still left to do. I’ll also go through the steps one might need to take on duplicating this design for another screen on a future blog.

©2025 by Steve Guttag

[Blog-16, Part 4 of 4, End of Blog]

[Steve Guttag]

I missed that Q-SYS is also canning the large Core. The Core 5200 (which I'm sure is going to affect all of us, greatly ). Normally, like for the 610 and 110f, they don't announce an EOL without its replacement in hand. The 510i they did but the 610 was its replacement back in the supply-chain days. So, what's a guy supposed to do if he needs a 512x512 system with about 1TB media drive?

The X20r tops at at a poultry 384x384 channels with an anemic ~500GB media drive...barely enough for a single screen (in truth, it is a little more powerful than a 610 with a scaling license). The X10 replaces the power of the 510i minus the cards, which Q-SYS is dropping altogether in favor of the QIO style (I prefer the cards, though not in the Cores).

Anyway. Since Dell made the large Cores...one would think that the next large one would also be a Dell. I'm betting that even the Core 610s will prove to be longer lasting (hardware wise) than Q-SYS made 510i hardware. What's the service life on a Dell server? Fortunately, I don't think any cinema, even big ones, will need to worry about the larger Cores as I think the Core X20r will handle just about any sized plex.

[Steve Guttag]

Since the period of time has passed for when I can edit the above post...please disregard. The Core 5200 was accidentally given the EOL with Stock status. It remains active/current. So, there is no excuse, anymore, for not making all screens Q-SYS!

[Leo Enticknap]

10.0.0 is out; those who registered with QSC to do online training should have gotten the email with the download link (unless they're not emailing everyone at the same time, to manage download bandwidth).

One significant gotcha is that you must update to 9.13.0 if a core is currently on 9.1 through 9.12: if it's on 9.0 or earlier, additional step upgrades are needed. And of course, you would need to check that none of the hardware in your installation has been consigned to e-waste by version 10.

[Steve Guttag]

Though not officially published, 9.13 will be the new LTS version. Given that 9.13 has a lot of complaints against it, they are, no doubt, "fixing it" so it is worthy of LTS. Most things used in typical cinemas are covered by 9.13 except notably older Cores and the I/O 8S. The normal 4-card I/O Frame is good in 9.13 (as is the TSC-7, either wall or table mount). Dataport amps (DCA) are definitely going to be left behind in QDS 10 and beyond. Core 510s can support Dataports and QDS 10.

I could see some market, once they are not hot items where they could be used as just an I/O-frame in QDS 10+ once they are low-cost on places like eBay. The A/V market is done with analog amplifiers like the CX or DCA, so there isn't a big outcry.

I've also thought about using a Nano running 9.13 to talk with I/O Frames in 9.13 while the main Core, like an X10 or X20r would be running in 10.x and beyond. Use QLAN Transmitters/Receivers to move the audio between environments and Control Links for any data that you want to move between the two. The realities are, this is for legacy equipment and possibly a screening room that will want the quieter amplifier (DCAs are MUCH more quiet than CX-Q).

[Steve Guttag]

There is no two ways about it. This is going to be a long one (mostly due to the screen shots). So, let's start with some eye candy for those that enjoyed the 70mm film era of the 1980s.

Q-SYS For Cinema Blog-17, UCIs (Sample 7.1 Part-12)

Blog17Image0.png

Current QDS Versions: 10.0.0 and 9.4.8 LTS.
Sample 7.1 design version: 4.3.0.0

Introduction

In this blog, I’ll begin the discussion on UCIs (User Control Interface). The subject of UCIs is far more than can be covered in just a blog or two. One could make an entire course just on effective UCIs. So, this will be one, in what will likely be a series of UCI discussions (not necessarily in a row). This one will start with the high points.
Note, though QDS 10.0.0 is now out, since all of the blogs on the Sample 7.1 have been using QDS 9 (both 9.4.8 and 9.13.0), I will continue to do so for these remaining Sample 7.1 blogs. My personal recommendations, as of this writing are 9.4.8 LTS, if your design/equipment doesn’t need a later version or 9.10.2 if you need 9.10 or later (currently shipping DCIOs, Core Nano and Core 8-flex).

Disclaimer

If any of the content in this blog happens to show up in a Q-SYS exam, it is not my intention to provide an answer-sheet beyond the discussion of good practice. I have not seen any form of the cinema final exam (my Level-1 was before there was a cinema version).

Disclosure

I do not, in any way, work for QSC/Q-SYS. These thoughts are my own based on my own interactions with the product(s) and implementing Q-SYS within actual cinema environments. I do work for a dealer that has sold QSC products since the 1980s, including Q-SYS and its predecessors. For the purposes of this blog, I represent only myself and not my employer(s) or any other company.

UCIs

UCIs are, really, where a lot of variations will happen. It is in the mind of the beholder as to what makes sense, in terms of how to interact with the system, at the user-level. Ask 10 people to design a UCI for the same space using the same schematic, odds are you will get 10 very different designs. With more experienced designers, you’ll likely find some commonalities, that are acquired through actual interaction with users. This is how one finds out what “works” and what seemed like a good idea but doesn’t work well (one needs to find out what isn’t understood by the user or just isn’t used).

Note, UCIs do not always mean “touchscreen.” Touchscreens, historically, are the main form of UCIs. However, any form of user control is a UCI. The DCIO has a physical volume control and mute button. Those are user controls and are part of the UCI. You may find that using the GPI of the DCIO and the fader/mute controls are sufficient for your use-case. How many people are actually going up to a cinema sound processor? How much do you want to spend on touchscreens and other controls for people to never use?

You could have little to no physical controls at the individual theatre yet provide an extensive control/status available via a web browser or app. What is best will vary by use-case. As with most things Q-SYS, you can adapt the system as the needs change.

My UCI Design Philosophies

Less is More

Probably the biggest recommendation I could make on designing UCIs is to really consider what you are putting into the design. If something doesn’t bring something to design (and it will actually be used), then it is bringing clutter and is actually distracting to the design. If you put 10 buttons on a page and only 5 are going to be used, you’ve not only wasted the time locating those 5-extra buttons as well as mapping them, you’ve created unnecessary confusion because the user has to see those buttons and decide that they are not ones that are needed. UCIs are definitely a case of “Less is More.”

Pay Attention to Color Combinations

It may seem like a trivial thing but having clashing color combinations make the UCI difficult to see/read and use. You’ll want to use a client’s color schemes, if possible, as it does provide a nice degree of customization. Learning about CSS (Cascading Style Sheets) will aid in this as you can change color schemes, globally, within a UCI design.

Here is a video from the Control & UCI Intermediate Training:
CSS Basics (part-1)

Q-SYS offers three levels of Control and UCI Training…beginner (logic blocks), Intermediate (Block Controller) and Advanced (scripting).

A quick test for a color combination is to convert it to B&W. If the contrast between the buttons, background and lettering are not readable or clear in B&W, then they are bad in color too (trust me).

For example, here are a couple of buttons:

Blog17Image1.png

Red on Grey is a bad color combination that is difficult to see/read.

Blog17Image2.png

In B&W, the red text starts to blend with its grey surroundings. Compare that to the other button. Regardless of color or B&W, the contrast between text and background are clear.

Grouping, Colors, and Spacing of Controls

You’d be amazed at how adding Group Boxes around buttons can make the usability of your UCI much easier to use.

Likewise, using button colors can be used to make the UCI easier to understand.

Space can also be used to provide clarity and make finding the right button or control go much faster.

This is a hard-to-use way of arranging the format buttons:

Blog17Image3.png

They are not grouped. And worse, they’re arranged in a tight grid. To find the button you want, you have to scan the whole thing. They are all the same color and the arrangement has no grouping with respect to what each format does.

Compare that to what I showed in Blog-13:

Blog17Image4.png

It’s the same buttons (actually, one extra because I was discussing adding a Trailer 7.1). They are almost in the same grid but there are three group boxes as well as how the buttons are arranged that makes finding the button you are looking for significantly easier. Perhaps grouping the Trailer and Feature buttons separately would be better or maybe using colors to make locating Trailer versus Feature versus 7.1 versus non-media/non-sync formats. There is no one right answer but how you arrange your controls can have a big impact on how useful they are.

Observe How Your Client Uses the UCI

It isn’t the client’s fault that they don’t understand your UCI. One of your design goals is that your UCI is self-explanatory. Sure, not everyone will understand some nuance to a feature that you added (or were requested to add) but all of the day-to-day stuff should make sense to anyone wanting to use the system, without needing an instruction sheet.

When you deploy a system, or send screen-shots of your UCI concept, observe if the user is able to figure it out or if they get confused. If they get confused, see what it is that they are getting stuck on. Figure out how you could make the UCI better/easier.

When in doubt, keeping the UCI simpler will be the better choice. It’s great that you can fly in layers and do some animation with CSS but the goal is user-operability and not to be flashy. Don’t get me wrong, if you have an intuitive UCI and you want to spruce it up with some nifty graphics or animation, by all means, go for it. Just make sure that you retain the ease-of-use aspect.

[Blog-17, Page 1 of 5]

[Steve Guttag]

Sample 7.1 Home Screen

Blog17Image5.png

While the provided Home screen is fine for a sample, it isn’t what you would want for a deployed system. The biggest problem, on first sight, is the company logo smack dab in the middle of the background. If you put a logo in the UCI, you shouldn’t obstruct it. So, now you will have to build your UCI around that and leave valuable real estate open. You wouldn’t want a UCI that looked like this (would you?):

Blog17Image6.png

Think about your favorite cinema processor(s). They could be from the film era or digital cinema. What do you like about it/them? Now see if you can emulate or, at least, take the good points from that and put it into your UCI while adapting it to the needs of theatre you are designing for. Unfortunately, for me, my favorite film processor remains the Dolby CP200. It was impressive. With 1970’s technology, the UCI (front panel) could support up to 100 formats, 4 film projectors, multiple faders/remotes, 4 presets could be loaded it, at a time. And, it could bypass most portions of unit, if there was a failure. It did all of that without software, Ethernet, or even RS232. That’s a lot to ask from a UCI.

But think about your favorite cinema processor and what features it had on the front panel and what made it particularly good. If you think about it, most were not all that flashy and they don’t need to be. They need to be clear and convey information quickly while also providing controls that the user will need/want.

Now look at the Sample 7.1 Design. What do you think it needs? For me, I would say meters, or at least signal presence indicators (SPI). If you are a fan of the QSC DCP series of cinema processors, it had SPI instead of meters (space is at a premium, particularly on a small touchscreen).

Blog17Image7.png

The Sample 7.1 Design UCI has meters but they are on their own page. That is fine to have a meters page but if they were on the Home screen, the user would know, at a glance, that sound was getting into the system. Odds are, if someone is looking at the UCI (particularly if they are standing by the sound system), something is up with the presentation (shows are almost universally automated).

Something like this:
Blog17Image8.png

Now, the meters should be formatted a bit better (I just copy/pasted). The spacing/color should be consistent with the design. They may even be better in a different part of the screen. They need not be big either. They need to be just big enough to let the user know that there is sound coming in and on which channels. I’ll show you one of my UCIs a bit later in the blog and identify the thought behind what is on the home screen.

In general, I think you should try to put as much of the day-to-day stuff on the home screen without it feeling “busy.” You want to minimize the need to change pages for most day-to-day operations. You want as much info right up front as possible that pertain to showing the movie or indicating a problem.

Pages and/or Layers

When making a visual UCI (touchscreens, UCI-Viewer, Web based), you can use a combination of pages and layers. The most basic/minimal is 1-page and 1-layer.

The simplest way of think of pages and layers is that a page is like a piece of paper. The page can have its own color but other than that, everything that goes on a page goes on a layer. Layers are like transparences. So, you can have multiple layers visible at one time. Layers occupy 3-D space such that you can locate layers above other layers upon a single page.

With that knowledge, you can completely obstruct a lower layer (to effectively “flip” the page) as well as have multiple layers visible with different aspects of the UCI being on different layers.

Traditionally, everything was done with pages (layers were not an option back then). Once layers were introduced, the “cool-kids” switched over to using layers. That is, you still have the one page (layers live upon a page) but all transitions are done by making layers visible/invisible (or combine the layers with multiple layers visible). There are also “Shared Layers” that can be used with multiple pages.

The Sample 7.1 Design uses a more traditional page-based system (each screen, Home, Monitor, Meters, Clean Screen are on a separate page with a single layer). You could do the exact same thing with just one page with a separate layer for each category that I just listed. The experience to the user can be the same. You are just turning the visibility of the layer on/off the same way you would have changed pages.

I’ll use my alteration of the Booth Monitor from a previous blog (Blog-15) as an example of how to use layers.

It looked like this:

Blog17Image9.png

In terms of the page and layers, this is the construction:

Blog17Image10.png

The page is the “Monitor Mixer” and the layers are Amplifier, Processor, and Background. The Background and Processor layers are visible. The Background is lowest-level layer so everything above it appears above it on the UCI

Everything except the buttons within the white group box are on the Background layer. The buttons within the group box, in this case the Processor buttons, are on the Processor layer. The buttons for the Amplifier monitor are not visible. When the user presses the “Amplifier” button above the group box, the layer visibility is changed, and in this case, using a UCI layer controller, to make the Amplifier layer visible and the Processor layer invisible.

Okay, another refresher from Blog-15. There is a 2x1 audio router that chooses between Processor audio and Amplifier audio (to feed the Monitor Out). The buttons from that router are what were placed on the UCI (background layer) to provide both audio and layer switching. The router pins were exposed to control a UCI Layer Controller component to switch the visibility of the layers.

Blog17Image11.png

[Blog-17, Page 2 of 5]

[Steve Guttag]

UCI Layer Controller

The UCI Layer controller (RSP component) properties let you set up what page it will control its layers.

Blog17Image12.png

The Control Pins portion will self-populate based on the layers you add to the page and what you call them. Since I wanted to control the visibility of Processor and Amplifier layers, I exposed those pins.

The UCI layer Controller does give you some transition options (various wipes and fade) as well as leaving it as an instant change (none).

Blog17Image13.png

There are some implications here. If you have multiple UCI instances (web page, touchscreen(s), UCI-Viewer), they can all be on different pages…but layer visibility would be the same for all. If a layer is visible, it is visible. This can be a feature or it could get in the way if two people are doing different things. Pages keep things more unique to each user. Of course, you may create separate UCIs for each user based on the needs of the user. For instance, you might create a UCI that controls nothing but volume controls in each screen. It would be a different UCI than the one driving the touchscreen for a particular screen.

One of the reasons some like using layers has to do with scripting. The UCI Layer Controller is just one (easy) way of controlling layers. You can also control them via the various scripting methods, including Block Controller.

A caution when using the UCI Layer Controller is if you change the names or order of your Pages/Layers, the wires/pins of the layer controller will disappear (since it self-populates based on what you call things and how your order things) and you will need to re-expose your pins and add the wires back.

I have favored a combination of pages and layers for my UCIs.

So, we have a layer-controller to control what layers are visible on a page; but how do we switch which page is visible? We have choices.

• If you are on a Touchscreen, you can enable “swiping” to switch between pages. This can be handy on smaller touchscreens to not devote real estate to navigation buttons/tabs.
• Tabs (configured in properties). Tabs can be horizontal or vertical. You can have them on whatever side suits your design’s needs. There are couple of tab styles to choose from too. You do have some control over the tab size but as your tab count increases, you may find that it is difficult to fit the names of your tabs on the available space as their size is also a function of how many have to fit in the available space.
• Navigation Buttons.

Sample 7.1 Design Pages

The Sample 7.1 Design uses Navigation Buttons (RSP component, just search on “Navigation”). I’ve rearranged them a little bit:

Blog17Image14.png

I added the HOME button to the HOME screen too. The reason is so that the buttons are consistent from screen-to-screen as well as, if you press a button, think about where your finger will be when the screen switches. You don’t want it jumping somewhere else or operating a control that happens to be where the button was on the other page. Think about the Navigation Buttons as if they are on your background layer.

I’ve already shown the Monitor Mixer (which I added in Blog-15) above. The METERS page is just a collection of meters, both processing and amplifier.

Blog17Image15.png

The Clean Screen is so you can clean a touchscreen without having it do bad things like switch to the home page and raise the volume all of the way up. When you press the Clean Screen button (RSP component), it disables the touch function of the touchscreen for 30-seconds. It is rather well un-documented.

Blog17Image16.png

Button and Text Sizes

When laying out your UCI, think about your button and text sizes for your intended device. If it is going to be on a small screen, like the 5-inch touchscreen, use the magnification within QDS to simulate the actual size. Can you still read the text and will a normal user be able to reliability touch the controls they want? Layers can be a great way of expanding the real estate of a small screen. You will also, likely, need to exaggerate your button sizes so on the smaller screens they appear usable.

Here is one of my server control screens. It is on a TSC-50-G3 (5-inch):

Blog17Image17.png

The buttons may appear large but on that small screen, they are appropriate. If you make them too small, they become difficult for the user.

My Cinema UCIs

I do not proclaim to be the end-all of UCIs. In fact, there are some really snazzy UCIs, by others, that are just incredible. Mine are more pedestrian and about user-control rather than being flashy. A common theme of all of my UCIs is how I lay out the Home screen. As mentioned earlier, I like to cover a lot of ground there to avoid having to change pages/layers.

So, here is one of mine:

Blog17Image18.png

In the UCI, note some of things discussed above. Group boxes, including stroke thickness have been used to group buttons/controls. I’m using pages with the tabs across the top and with the chevron (tabs have points to them) style. In addition to the text on the tabs are icons to also help find the page you want faster.

There is a Bypass button, with indicator (if you are in Bypass, the LED will be flashing to alert you that you are still in bypass). The Bypass button is a Popup Button that allows the user to bypass around the problem channel(s). Again, the Popup Button is being used to expand the “real estate” of the UCI.

Blog17Image19.png

Because the Barco S4 projectors have omitted taillights, we have placed that indication on the Home screen too (Projector Status).

The Presets are grouped to put the DCP buttons together. The Mic has a different color button because it can be added, regardless of what preset may have been selected (voice overs/panel discussions when other sound formats may be needed for a presentation).

The typical fader controls are on the right. The “knob/fader” serves mostly as a visual indicator as most people will use the up/down buttons. The buttons are of the ramping style so one can tap the level up/down or push-and-hold for a more rapid raise/lower. The Mute button flashes, if it is active.

Over on the left side, the amplifier on/standby indicator lets the user know that the system is on. The Amplifier Power popup button allows for manual amplifier control. I’ve found that if a touchscreen gets dirty, particularly with fingerprints, you can get phantom button presses and if it is on the amplifier on/standby, it can have consequences that are not pleasant. Hiding the on/standby button in the popup button eliminates that problem.

The big “OK” box is a Status Combiner status. If everything is operating properly and on, it will read “OK” and will be green. If any other condition exists, it will either have words in it or the color could be orange (compromised), blue (initializing) red (fault). Tapping the Status button will open a popup button to provide more detail on what is having an issue:

Blog17Image20.png

That red “LED” on the Status button flashes if ANY of the amplifiers are muted. It is really easy for a user to tap the physical buttons (tapping the physical power button will mute all) on the CX-Q (DPA-Q) amplifiers and you’ll have a no-sound condition. The amplifier isn’t in a fault condition so their status will be “OK.” That LED, combined with the Mute buttons within the Status Popup Button allows for both troubleshooting and correcting the condition (guess how I know about this one).

The meters at the bottom of page finishes the Home screen off and it gives a visual confirmation that audio is coming into the sound system (note, they are labeled Input Levels).

[Blog-17, Page 3 of 5]

[Steve Guttag]

For monitoring, what I have discussed with respect to the Sample 7.1 Design is implemented here:

Blog17Image21.png
Blog17Image22.png

Layers are used to switch between Inputs and Amplifiers. In addition to the button changes (and what is feeding the monitor speaker), the meters change to power meters.

I already showed the server screen above, here is the one for the projector (Barco S4, in this case) on a small (5-inch) touchscreen:

Blog17Image23.png

If you have a larger touchscreen/or iPad, you can combine some like things like the Server and Projector:

Blog17Image24.png

The server and the projector controls started with “Plugins” (more on those in a future blog) that can provide quite a bit of control that would, ordinarily, require separate applications or have a laptop/pad around. All of this is controllable via a Q-SYS UCI or multiple UCIs. In the case of UCI above, one can even choose what content to run (CPL or SPL; they are within a Popup Button). Q-SYS is, clearly, more than just a sound system.

The Mic control, depending on the system (if they even have microphones) will vary from a single mic input (using the DCIO’s XLR input) to a more complex microphone system with multiple mics that may need and auto-mixer and all of the way up to a speech system needing a more elaborate mixer.

Blog17Image25.png

Likewise, the Video system can vary greatly, based on the needs of the client/theatre. With the use of Blu-rays, laptops (including for zoom/team rentals), Q-SYS can be a handy control system.

Blog17Image26.png

This is another case where layers can be quite handy to allow for different controls based on the source being used:

Blog17Image27.png

[Blog-17, Page 4 of 5]

[Steve Guttag]

Your UCI could be nothing more than providing controls to a presenter at a lectern where they just need lighting control:

Blog17Image28.png

…and Laptop Control:

Blog17Image29.png

It doesn’t have to be big and flashy. It just has to fit the space (feature and size wise).

Video Control

I haven’t shown any NV video because we haven’t used them yet. But we have used Q-SYS to control conventional video equipment as well as AVoIT equipment (i.e. Visionary Solutions, which is a Q-SYS partner and their plugins show up in Asset Manager).

Blog17Image30.png

Since there is nothing connected to the laptop port, at the moment, nothing is showing on the encoder/decoder screens and the status is red (you’d want that indication if you had an event and there should be a laptop hooked up).

Depending on the equipment you choose, and how you control/represent it on the UCI, you could eliminate things like a preview monitor since the UCI may perform that function.

This theatre has an entertainment center, including a sports bar, bowling alley and arcade. Q-SYS is providing sound and controlling the video down there too:

Blog17Image31.png

As you can see, UCIs can show video from some devices and full motion video from NV endpoints. The images from the Visionary Solutions endpoints update at the rate of about once per second. So, depending on the refresh of the particular decoder, you might have noticed that various zones are showing a slightly different image.

Conclusions

Q-SYS is going to be thought of, at first, as a sound system. But clearly, it can be much more than that. It can be a control system, and a complete automation system. It can handle video too. Having effective UCIs can greatly enhance all of those experiences. Hopefully, this blog has given you ideas of how you could create UCIs that would be effective for your organization. If you have some UCIs that you’d like to share, I’d love to see them.

While I’ve shown touchscreen-based UCIs (and they are very handy for providing user controls), I cannot emphasize enough that touchscreens are not required. You may only need some pushbuttons to change formats (they worked for a long time for cinema processors). Or you might be fine with just browser-based controls (all modern servers have moved to web-based controls too).

Your cinema server isn’t going to use your UCIs. It is going to use ECP or another form of network control. UCIs are for “Users.” What you chose to do with it is up to the sites needs and your imagination.

©2025 by Steve Guttag

[Blog-17, Page 5 of 5, End of Blog]