Q-SYS Corner

[Elia Orselli]

I'm guessing that should probably work...it would be better if the Gain Ramp worked in emulate mode so you could flesh everything out before pushing it live.

I agree I had to turn on my spare core to try

[Leo Enticknap]

Many thanks, Steve and Elia. The nearest I managed to get was a gain ramp component operated by a crude block controller script that recorded the fader setting before the mute was triggered, offered a "fade to mute" button, and then set the fader to the stored level with the mute engaged, such that pushing the actual fader's mute button would give an instantaneous "back to where it was." But that meant two buttons. Thanks again.

[Steve Guttag]

Q-SYS For Cinema
Blog-6, QDS–Part-2, Sample 7.1 Part-1 Overview
_1/1/25

Introduction

In the previous blogs, I have:

1. Gone over the concept of Q-SYS within the cinema environment.
2. Introduced the software (QDS).
3. Covered how to choose the right Core for your project.
4. Discussed the DCIO/DCIO-H, which gets the sound into and some cinema-specific sound out of the Core.
5. Discussed Amplifiers and Voicing.

In this blog, I will begin the discussion of the Sample 7.1 design. I’m choosing this design because it is available to everyone so those that want to follow along can look at the exact same design. There are also a lot of key points that can be discussed with its design.
The thought occurs to me that since QSYS uses the Sample 7.1 design in their training series for cinema, some of the items that I might discuss could show up on a final exam. I have not seen any form of the cinema final exam. When I went through the Level-1 training, there was not a separate cinema version. Depending on what is on the exam, you may find the answers in this or future blogs. There is no intent, on my part, to create a solution sheet, beyond the discussion of good practices.

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.

Step-1 Opening the Sample 7.1 Design.

First things first. Let’s get the Sample 7.1 design. To obtain it, you first must “install” it via Asset Manager from within Q-SYS Designer Software, QDS. I am, currently, using 9.4.8 LTS and 9.12.1, depending on the system. Either may be used during this blog.
Asset Manager is represented by a little puzzle piece. It can be opened in three different places.

1. Up by the Menus:
   Picture2.png
2. Over on the Right-Side Pane (RSP) in the “Plugins” section:
   Picture3.png
3. Or in the Tools Menu:
   Picture4.png

That should open the Asset Manager tab. Asset Manager has all of the Q-SYS sanctioned plugins made by Q-SYS and their registered partners (manufacturers, typically, but also 3^rd party developers). These plugins often are also incorporated into Q-SYS’ Reflect platform, if you are looking for an Enterprise or NOC type solution.

If you scroll around Asset Manager, you’ll likely happen upon some cinema specific plugins from our three primary projector manufactures, Barco, Christie and NEC (Sharp). There is also one from Dolby on their IMS3000 and from Integ for the JNIOR series of automations.

But, for now, we are interested in the Sample 7.1 design. The fastest way to find it is to type “7.1” into the search box. As of this writing, it will be the only thing that remains with that search.

If you select it, on the right side, you will have the option to “Install” it. Once installed, you’ll also have the option to “Remove.” Currently, it is version 4.2.0.0. If you want to match what I’ll be showing, you should ensure that you are using the same version. If you have an older version, you can either “upgrade” or Remove and then Install. This may also be necessary if you installed it on an older version of QDS and the sample design isn’t in the correct folder for the version you are working with.

Once installed, you will then need to open the Sample Design. If you go over to the File menu, click Open Sample Design (CTL-Shift-O). Depending on what other sample designs you might already have, it could be the only one offered. Double-Click on the “cinema-sample-7.1_v4.2.qsys” file to open it up.
Picture5.png

At that point, you should be looking at the same design we’re going to be working with for the next few blogs.
Picture6.png

If you’re still with me, let’s begin.

Overview – Design Styles

In this blog entry, I’m just going to concentrate on the “big-picture” items (e.g. design styles/techniques). In future blogs, I will go into the signal flow and other design techniques but it is important to consider the stuff that has absolutely zero effect on the sound as well.
If you want to jump ahead and get a video overview of the design, this link will take you to the part of the Level-1 training videos where Patrick and Nate go over the Sample 7.1 design.

Level-1 Training Sample 7.1 Walkthrough

Disclaimer

I had absolutely nothing to do with this design. I am neither endorsing or judging it. It is being used as a training design and a common building block. You are welcomed to start your design(s) using the sample design as a starting point, if not a substantial part of your design.

The designer of the Sample 7.1 chose to have the audio signal flow move across the top half and put all of the control items on the lower half. Keeping the signal flow reasonably linear allows one to, quickly, follow the signal path, without having to jump around. You’ll likely find that the audio signal path is easier to figure out than the control one, since control doesn’t have a linear path (this is not a critique; control paths do not have an inherent linear progression). Imagine if the audio path jumped around all over the design. It would be much harder to follow.

Key Item: When I refer to a Signal Name (aka “wiretag”…I use wiretag and Signal Name interchangeably), I am referring to the arrow shaped icon that attaches to a pin on a Q-SYS component that display’s the Signal Name.
Picture7.png

Signal Names can be used for any signal where a wire could be used (audio, control, video…etc.) and they have the same rules as wires (including one source can feed multiple destinations).

This is a link to the training video on how to use signal wires and signal names. The subsequent video will show signal snakes (aka Wire Snakes).
https://training.qsc.com/mod/book/view.php?id=883

In the Sample 7.1 design, the Signal Name colors were chosen based on where they are in the signal path (they go from pale-blue, blue, pale-green, orange). There are other colors for the non-primary channels, like the HI/VI signals that don’t go through the normal “B-Chain” tuning. This sort of planning and consistency will go a long way towards making your design easy to follow. This could pay off in dividends when there are problems and one needs to troubleshoot to be able to quickly locate the point in the design were the problem shows itself.

There isn’t a standard for color. It is up to the designer. In fact, in my designs, I use color to signify the channel. For instance, in my designs, red is used for left channel, throughout.

Though covered in the Level-1 training (and I cannot emphasize it enough, that you should go through the entire level-1 training), changing colors for components, Signal Names and most things is a simple matter of selecting the component (or group of components) and changing the “Fill” color on the RSP.
Picture8.png

You can go crazy with colors, if it suits your needs. If you are using one of the predefined colors, you’ll see it boxed in red (see 4-rows down and 5 over from the left in the example above). That is the color the design is using for the input signals. Also note the “Design Colors.” That should represent all of the colors that are in use in your design. This can help you be consistent.

[Blog-6, Page 1 of 3]

[Steve Guttag]

Grouping and Boxing

Throughout this design, they have used grouping. There is more than one type of grouping. For this part of the discussion, I am referring to locating like-things together to break the design up into logical groups and putting a box around them. In a future blog we’ll discuss component grouping where multiple design elements are physically grouped such that they are treated as a single component.

You can find all of the grouping and text tools on the Right-Side Pane in the Graphics Tools:
Picture9.png

For a video on how to use them please click here: Graphic Tool Video

So, for the audio path, we have: Inputs, Processing, Equalization, Outputs, and Speakers. Group boxes are around each of them. Colors for the background (dark blue) and each group (grey) are used to not only create a theme but also make the design easier to follow.

What if all of that was removed (or never added) and we just go with the standard background and no group boxes?
Picture10.png

It’s the same design. It will work exactly the same. However, now it looks more like a jumbled mess. The components are still located in logical places. Some, like the Booth Monitor Router, are starting to look randomly placed.

Let’s take it a step further. Let’s get rid of the Signal Names and do most things with wires (at least for the audio path).
Picture11.png

Again, this is just as functional as it was when we started. But it is a mess, from a design perspective. The wires are like spaghetti, which makes it hard to follow or troubleshoot.

Now, it is VERY common for designs to start similar to this and then get organized as it develops. However, it will help if you start with some amount of planning at the get-go. If you have a color scheme you like, use it. Think about your organizational desires and start with them rather than trying to fix it down the road.

When to use Wires versus Signal Names (and Signal Naming techniques)

Let’s look at the first two groups of the design, “Inputs” and “Processing.”
Picture12.png

The more destinations a source needs to go to, the more you should think about using Signal Names. This is particularly true if the destination is not close by or on another schematic page. If you are using wires, they should add clarity in addition to speed.

Again, I didn’t design this one but you should find it interesting that they used wires to connect the Inputs to the Processing but Signal Names for just about all of the rest of the audio path. Why? If you have been following along with my blogs and refer back to my first one on QDS (Blog-2), Inputs and Outputs are Left-Side Pane (LSP) components. LSP components do not copy from design to design. So, if you were to create a Screen 2 by copying all of Screen #1, what would happen?
Picture13.png


The DCIO-H disappeared and so did those wires. So, we need to add another DCIO-H for Auditorium #2:
Picture14.png

So, if all of those were Signal Names, you’d have the overhead of recreating them instead of just dragging 16 wires between components.

What else do you see about what happened when the design was copied from Auditorium 1? Check out the names of the Signal Names (and components). Most of the Signal Names are named correctly for auditorium 2 (A2).

Q-SYS will not allow you to reuse the same name of components or wires if it would create a conflict with an existing wire or component. It will append a “1” to the name or, if there is a number there already, it will increment it by 1. How handy is that? Note, since you can have a source go to many destinations, that isn’t a violation on a copy. Also, since the DCIO wasn’t part of the copy, the Signal Names on it, were not copied and there are “A1” Signal Names in our A2 design. All of the custom named components (e.g. “Routing”) just got appended with a “1” too. What would be better is if you name a component that you also append the name with the “A1” or whatever screen number it is so that QDS will update the name on subsequent copies. Components that you leave with the factory default names do not need to be appended…but, internally, for reasons of scripting access, will be appended. This will show up on later QDS versions, like 9.12.1 in the properties section in the RSP.

So, it would be best, before duplicating the auditorium, if you were to go through the design and modify the custom names with the auditorium number. But we’ll go over duplicating auditoriums in a future blog.

These are the little things, that if you take a little bit of time, up-front, will pay dividends to saving time down the road. And, the more you do it, the more it will become second nature.

[Blog-6, Part 2 of 3]

[Steve Guttag]

Containers Text, and Popup Buttons

Continuing with the organization theme, the use of Containers, Text and Popup Buttons can be very handy.

Containers

Key Point: A container (RSP component) is incredibly powerful. A container is like a self-contained schematic unto itself. It can have signal pins, just like functional components where you can pass signals into/out of the container. It can have multiple pages too. The Container can be locked, if desired (so it can’t be opened), to provide functionality without providing your actual design. Containers can also be nested. I’ll revisit the Container component in future blogs as we utilize it in different manners.

In the Sample design, they are not being used to pass signals in/out or with multi-pages. In fact, all of the Containers could be changed to Popup Buttons but there is nothing wrong with how they are being used.
Picture15.png

The “AMPLIFIER OUTPUTS” and the “LOUDSPEAKER LISTEN BUTTONS” in the image above are Containers. Double-click on them to open them up. A benefit of Containers, over Popup Buttons, is that you can move the opened Container to where it is convenient.
Picture16.png

Note the text used above/below the Containers to give the user some information about their use. While you are designing a system, everything might be fresh in your mind; how about years down the road? These sorts of notes can be lifesavers in figuring out the design when things are not so fresh in your mind or for someone that didn’t make the design.

In the bottom-right section (GPIO & CONTROL), check out the “Relay Pulse Buttons.”
Picture17.png

You can put most anything in a Container that you want.

Containers can really clean up a design while putting the functionality there without having to flip around to multiple pages or all over the schematic. In the case of the Relay Pulse Buttons, putting all of those logic functions in the main design would cause clutter without making the design any clearer.

One of My Examples:

Here is a Container from one of my designs. I’ve put all of the B-Chain stuff in a container, since you don’t need them other than for commissioning. It cleans the design up. I also try to leave information for “others” as to how to use the design:
Picture18.png

If you were to open my container, it would look like this:
Picture19.png

I could have used the Signal Names directly within the Container but I think it has better clarity to keep all of that “wiring” visible in the main schematic and take advantage of the Container’s ability to have input/output pins to pass the signals in/out of the Container.

Popup Buttons

Popup Button are like single layer containers. You cannot “nest” Popup Buttons. Unlike Containers, Popup Buttons can also be used with UCIs, which can be VERY handy to conserve real estate on a touchscreen.

In the Sample Design, in the far bottom-right corner, they have an “Automation Command List” Popup Button. Double-Click on it to see what commands you can use on your server to control the Q-SYS processor.
Picture20.png

The commands are the parts that are within the quotes (e.g. csv NS 1 will switch the format to Non-Sync though it must be terminated with a new-line character \n (\x0A)).

Note that the Popup Button box is anchored to the button. The box can be located on any of the four sides. The box size is adjustable, as needed.

Control Section (lower-half of the design)

Things to note are that the “Status” blocks are all grouped together. One of the very powerful aspects of Q-SYS is its ability to provide a very quick/accurate status for most anything Q-SYS touches (not just sound, things it controls/monitors too). So, having a status section that conveys this information is a valuable piece to add to your designs.

Note, how they drug the status “LED” out of the component and placed it on the upper-left corner of each status component.
Picture21.png

This will give you a very quick, at-a-glance, way of seeing if anything is in distress. If you don’t see green LEDs…there is a problem.

What is unfortunate, is the color choice they had for the Status components. The green is the same as LED “OK” green. So, when the design is running (emulating or actually running on a Core), the green LED blends into the component itself:
Picture22.png

It would be best to change the Status color a little so the LEDs don’t blend.
Picture23.png

Also note that the LED for the “Status/Control Tsc55-1.” It is a little bigger than the other LEDs. It doesn’t change the functionality but it is inconsistent. If you are consistent, when something changes, you are going to be more apt to notice it.

Just like with the audio path, color theming is used throughout the control sections too:
Picture24.png

Statuses are green, Formats are red, Pink Noise is magenta. The Relays are a bit inconsistent. The buttons are blue but everything else is yellow.
The user controls are all grouped together. The technician controls are grouped together. And, finally, the GPIO and control stuff are grouped together.

Conclusions

This is a reasonable design and there is a lot to learn from it. We’ve just touched the surface of it to get an overview of how it is laid out. In future blogs, I’ll go through the audio path, analyze what it is doing, and look into some alternate methods of handling the audio and, possibly the control.

It is important to remember, the schematic is not an end-user environment. This is for the designer. The UCI (User Control Interface) is where you will present the controls to the user. However, the schematic is really where the UCI starts as well as any automation (including interacting with a server) starts.

©2025 by Steve Guttag
[Blog-6, Page 3 of 3, End of Blog]

[Leo Enticknap]

For me, containers have two major advantages.

• They enable the entire schematic to live in a single tab, which makes navigation and understanding the design a lot easier (especially if you're coming back to it after a number of years of not touching it).
• Security: by password protecting individual containers but not the entire core, you have complete control over what the end user, or another third party can do to your design, and what not, including repurposing it for another site.

For example, here is a design I'm in the final stages of working on:

image.png

The dark blue components are containers, and they all require a password to open. In another part of the design, EQ/tuning is within a container that has a unique password (it won't open any of the other containers), so that if the customer later has a Dolby tech wanting to tune the room, we can give him or her that password to provide access to those functions and no others.

Crucially, the password protected containers mean that if a core fails and needs to be replaced (for example), the end user or another service vendor would be able to do that without our involvement, but would not be able to repurpose our design for another project without doing a helluva lot of work, because things like the power management sequences and audio format presets are controlled by block controller components inside password-protected containers.

[Steve Guttag]

Thus far, I've been much more open about what it in my designs and not locked too many things though there is nothing wrong with locking stuff. One has to be careful on some contracts as often there will be a purchaser "owns" the design and everything contained therein. It can also tick off a client when a contractor, effectively, imbeds themselves to be essential to the upkeep of things. It seems like you have struck a balance there since, as you say, you need not be present if "others" need to go so far as replacing a Core, all of the locked Containers will just work anyway.

It is a balance. One can invest a lot of time (which equates to money) into a design or feature. One shouldn't be expected to just "give it away." At the moment, at least in cinema, there are not enough Q-SYS people in the industry, in my opinion, to worry about. Hopefully, that will change (in a good way).

For the "guest technician" I'm planning on having a separate EQ block with an A/B router. This way, you could lock your house-EQ and still allow for a guest technician to do their job for a screening. This also ensures that the house EQ can be restored without the overhead of snapshots (that would have to be updated every time you all were to retune the room...one false move and you overwrite multiple hours of work!).

And, for those looking in...please note how Leo has brought out the "LEDs" from the status of many components so that they are visible without having to open anything. And, for the Status components, the traffic light LEDs are visible. Any tech looking in will see, quickly, if there is a problem and where it is.

[Elia Orselli]

I've created 2 eq blocks with a router, as Steve said. Each block has a snapshot bank (to keep trace of changing in EQ settings both for my block and for "other techs" one) another snapshot bank controls the router. My EQ block is password protected, but the password is noted in a changelog schematich page, just to push other techincians to work on the correct EQ block.

immagine.png

[Leo Enticknap]

One has to be careful on some contracts as often there will be a purchaser "owns" the design and everything contained therein. It can also tick off a client when a contractor, effectively, imbeds themselves to be essential to the upkeep of things.

If you buy a DVD, you own it, but you do not have the legal right to modify or copy the video content on it. The same principle applies here. What we actually sell is an in perpetuity license to use the design we've created, in the form that we delivered it.

I started to password-protect containers in the aftermath of two incidents, one of which happened to me and the other to someone I know. In one, a Q-Sys design provided for one auditorium was modified by the end user and deployed in several others, including at different sites. In the other, someone took a design of mine and tried to add new functionality to it, broke it completely, and then expected us to come in and fix everything (including the botched attempt to add new features) at no extra charge. The culprit was a Crestron guy who thought that being one enabled him to dive in to Q-Sys Designer. Sigh.

If someone needs minor tweaks to a design (one that I have to do quite often is to change the amp model in a design when a first generation Q-Sys amp dies and is replaced with a CX.Q), we're always happy to do that, usually at no extra charge if it was a design that we created and installed. I'm also always happy to share my designs (unlocked) with others I feel that I can trust. But leaving one wide open to be buggered about with by anyone who wants to on a customer's core is, IMHO, too risky.

[Steve Guttag]

Elia, why bother with a Snapshot bank for the selector? It seems to me that you have a 2x1 router with 12-channel in/outs. You skip the need for a Snapshot bank...which are not portable, if you want to copy/paste or expand the design.

Screen Shot 2025-01-06 at 12.41.40 PM.png

[Elia Orselli]

You're right. I add the snapshot bank as solution for an event when during the same SPL was required to change EQ set (with the snapshot bank mapped as custom control and called with an IMS3 macro). The router would be a cleaner solution (and I'll adopt it in the next design update)

[Steve Guttag]

One of my goals (and it will show up in my Blog, most likely, many times) is it minimize the use of Snapshots when things like Routers can do the work. Every time a Snapshot is used, if the design is to be duplicated in some fashion, the Snapshot has to be, step-by-step, also duplicated...which, in my opinion, is a PITA. Don't get me wrong, Snapshots are very essential but I just try to use them when they are the absolute best solution rather than just the quick-n-dirty solution.

I'm thinking about going through my designs and seeing how I can reduce my use of Snapshots as well as mixers. I've used a lot of mixers instead of routers because they are more flexible. But that does come with a DSP overhead. Routers are, essentially, "free." The DSP doesn't really care or consume resources keeping track of what node connects to what node. But when it comes to levels, phase, mutes...and everything that goes into a mixer, they do consume resources. What I also want to do is things like use routers with ins/outs that make sense for the signal so one doesn't get the HUGE array that a router can be. I have pink noise routers that are painful to open (think Atmos designs).

[Leo Enticknap]

9.13.0 is out. New product support for AcousticDesign ceiling mount speakers (AD-C8T-ZB, SWZB, and HPZB), plus the HV-1-H-WE video endpoint. Bug fixes:

• Audio: The QIO-FLEX4A no longer fails to initialize.
• Audio: Resolved an issue related to a file handle leak while reporting QIO devices.
• Audio: The issue of audio loss on reboot with I/O 8-Flex and USB Audio Bridging, where audio may not be detected has been resolved.
• Video: The issue where NC-PTZ cameras do not stream when the preview stream "Streaming Mode" is set to 480x270 or below has been resolved.
• Video: The issue with NV-21-HU persistent logging, where the device failed to enable logging with the same USB drive after upgrading to 9.12.0 and downgrading back to 9.10.2, has been resolved.
• Video: Resolved an issue where NC cameras stop working, leading to an offline splash screen displayed on the video bridge, has been resolved.
• Video: Resolved an issue causing green distortion from the AV stream of the NV-21-HU Encoder after a few hours or a complete power down of the switch.
• Video: The issue with camera’s going offline while using ACPR (VisionSuite Plugin) with auto framing enabled has been resolved.
• Control: The issue causing fatal errors when adjusting controls in the Text Controller while the Lua editor is open has been fixed.
• Control: The MTR black screen issue, which caused the touch screen to go blank and required a PC reboot to resolve, has been fixed
• Control: The issue where the TSC-G3 USB-C cable orientation affects the status of the video bridge, causing it to show as "Compromised" when oriented 180 degrees opposite, has been resolved.
• Control: The issue with the TSC Gen 3 rebooting when connecting its USB cable for AV Bridging has been resolved.
• Platform: The issue with QIO, NL, and NM Series devices needing appropriate X-Content-Type-Options and HSTS headers in all HTTPS responses has been resolved.

[Steve Guttag]

Thanks Leo! Word on the street is that the 9.12 has been problematic. It looks like 9.13 is more feature based (new things) than fixes (it's got some, for sure). 9.10.2 seems to be the favored version of the main-branch, unless you are using one of the new things, like the NV-1-H-WE. Note, it only comes in white but there is an optional extra that has black inserts for it. Note, if you plan on 4K/60 4:4:4 video with it, its fan can get a bit noisy. It is PoE+, however. So, it can be connected with a single Ethernet cable (It's an HDMI wall plate interface, by the way).

[Leo Enticknap]

An updated version of the NEC projector plugin is now available, as so:


image.png