Basic Q-SYS Signal Path

Let’s start off getting a better understanding of the Q-SYS system, by diagramming some basic signal paths—both in the software, and in the real world.

Although the sizes of designs can vary wildly, every design is going to have a Q-SYS Core, running the Q-SYS operating system.

In Q-SYS Designer Software, this is the only object prepopulated in your Inventory when you start a new design, and you can select which model Core you will be using in its properties.

There is a wide variety of Core models available, some of which include onboard audio inputs and outputs.

The next device in every design will be one or more network switches.

Your Core must be connected to one of the ports on one of your network switches, so that it can communicate with any other devices in your design,

such as native Q-SYS products or third-party devices—that are connected to other ports on your network.

The switch itself is not represented within the Q-SYS design in any way,

but your switches do need to be configured with certain protocols in mind in order to make sure that Q-SYS network traffic—known as Q-LAN—will work properly.

Q-LAN is simply a collection of standard IT protocols and priority levels that make Q-SYS audio, video and control transport possible.

To make this easier, QSC partners with major switch manufacturers to offer preconfigured network switches that work with Q-SYS right out of the box.

But most modern configurable switches can be configured to transport Q-LAN traffic,

with a little help from our Q-SYS networking requirements documentation, that can be found online.

You’ll design your system using the Q-SYS Designer Software, on a PC or laptop running Windows.

You can construct almost everything in your design without connecting your PC to a single Q-SYS device,

but it will need to be connected to your network in order to deploy your design to the Core.

In Designer, that’s called “Save to Core and Run,” which sends the design across the network to the Core, which then uses that design as its system instructions.

Once you’ve sent your file to the Core, your PC or laptop no longer needs to be connected to the system:

the Core will continue to run that design as long as it is running—and every time it boots up—until you send it a new design.

Let’s add some analog audio to this design.

In the real world, audio sources can be physically wired to any audio input, which can be found on some Core models,

or on a peripheral device, which we’ll talk about momentarily.

In the software, those physical inputs are represented by “Mic/Line In” components associated with that device.

There’s no need to represent the audio source itself in Q-SYS: Q-SYS doesn’t care if it’s a microphone, or a media player, or anything else...

it just cares that audio is entering the Q-SYS environment via this input channel.

Within the software, you would virtually wire that audio channel through any number of digital signal processing components,

which are available in your Schematic Elements library.

After all the mixing, processing, and routing, you would wire the audio channel to an output of your choice.

For example, this might be an analog line output on the Core itself—which could be delivered to an analog amplifier in the real world,

which would in turn be physically wired to some loudspeakers.

In this case, those analog amplifiers and loudspeakers would not be represented within Q-SYS,

because all Q-SYS knows is that the audio is leaving the Q-SYS environment, and you can then do anything you like with it in the real world.

(Although you might want to provide some inline speaker tuning, which we’ll talk about in later videos).

However, QSC also has amplifiers and loudspeakers that are networked Q-SYS devices themselves.

If you’re using a networked amplifier, this device would be represented within Q-SYS, as well as the loudspeakers it is connected to.

In the real world, these devices just need to be connected to the same network, and the Core sends its audio to the device via a “network audio channel.”

Many Q-SYS peripheral devices offer additional audio inputs and outputs beyond what is available on the Core itself.

These networked IO devices would generally be placed close to the physical input or output device in the real world,

and then transport those audio channels to the Core via another network audio channel.

Remember, different Cores can handle different numbers of network audio channels, which might largely be what determines which Core is right for your venue.

You’ll notice there’s no need to route any network audio channels inside the software.

Here, a microphone enters Q-SYS via an IO device and is delivered to a networked amplifier.

Even though the design makes it look like there’s a direct connection between the IO device input and the amplifier output,

all channels are automatically routed through the network to the Core for processing.

Some types of audio might actually originate within the Core itself.

For instance, the Core’s onboard audio player, or any of various available network streaming receivers (such as Dante)

can be used by the Core to introduce audio to the system without a physical input.

These audio types do not use up a network audio channel until they are delivered to a networked IO endpoint or networked amplifier.

You may have already noticed that the Q-SYS Designer file is essentially a flow chart.

Components generally have connection points (called pins) on their sides.

Channels flow from left to right, meaning that left-side pins are always inputs, and right-side pins are always outputs.

Because of this, we generally recommend that you build your design with components from left to right as well,

unless you’re a monster person who does it like this, in which case, you do you, buddy.

This same mentality applies to control and video channels as well.

Control pins have a different shape than audio pins,

and most audio components have control pins that can be added to them that allow you to control different aspects of that component.

Similar to audio, control might come from the real world, such as a physical button, a potentiometer, or the like,

and enter Q-SYS via a GPIO port, available on many Q-SYS devices.

Alternatively, controls might originate within the Core from custom digital buttons, or control pins from any other component.

Also much like audio, control wires flow from left to right, with all this processing taking place within the Core.

If controls are sent to third-party devices, this likely takes place via virtual components like third-party plugins,

network command strings, or scripting components—but might also include physical outputs like the previously mentioned GPIO connections.

Control components will be covered briefly in this Q-SYS Level One course, but far more extensively in our Control 101 training course.

Video components similarly have their own source components, routing components, and outputs, and are covered in more depth in our Video 101 training course.

Many installations will also require some degree of graphic interface to give the end user control of the system.

This user control interface—or UCI—is also built within the Q-SYS Designer software,

largely by incorporating the controls found within the various components used in the design, and is fully customizable in appearance and in style.

This UCI is traditionally delivered via a Q-SYS touch screen, which is another networked peripheral device, but it may also be deployed to iPads, iPhones, smart phones, and PCs.

You might even deliver your UCI through a dedicated in-room UC platform device.

So in summary, designs can be simple or incredibly extensive, but these basic principles will always be the same:

The Q-SYS OS drives the design file on the Core processor.

Audio, control, and video enter Q-SYS via Core inputs, network connections, or networked peripheral devices.

After being processed by the Core, audio, control, and video exits Q-SYS once again via Core outputs, network connections, or networked peripheral devices.

And control of the system is provided to the user via a custom-designed user interface.

And it’s worth mentioning: even though one Core runs one design, larger installations might use multiple Cores running multiple designs …

and there are component that allow those Cores to stream audio, video, and control channels from one design to another across the network.

We’ll look at the specifics of these devices shortly. Let’s take a break, and move along whenever you’re ready.