UCI Toolbox

When you first start building user control interfaces,

you're likely gonna just drag the controls you need straight outta the control panels of the components and drop them onto your UCI page.

And honestly, 90% of the time, that's how I do it.

But different people have different workflows.

So what if you're tasked with building the user interface for clients, but the engineer who's designing the signal processing hasn't completed their task yet.

Or what if you're planning out your UCI ahead of time, but you just haven't added all the components to your schematic page yet?

That's where the UCI toolbox comes in.

The UCI toolbox is kind of like a real toolbox.

It's a, it's a box full of tools, which I know a lot about 'cause I'm a, I'm a manly, I'm a manly man.

I bust out the old, uh, the old toolbox all the time.

You know, three to three, three to seven, three to three to eight, eight times a day, every hour.

I'm just, I'm tool boxing tool, boxing it up.

They call me the box.

I can't even stop 'em.

They just call me that.

So, let's look at the tools in the UCI toolbox.

You'll find it as a second tab in the UCI editor window.

Here you'll see a variety of objects and graphic tools that you can add to your UCI.

You might consider these controls to all be blank.

It's like a light switch that isn't actually wired to anything yet.

You can place it on your UCI and edit its appearance and then wait to connect it later.

When you're ready, you'll see that pretty much every type of control available in Q-SYS is represented here.

Different types of buttons, knobs with various ranges and units of measurements, text boxes,

faders with different visual styles, non-interactive indicators like a basic LED or text field,

and the same graphic tools that are available in your schematic elements library.

As you add these to your UCI, you'll see they also populate as individual items in your layer window.

The icon will show you what type of control it is with a description and the name of the control as well.

In fact, any control added from the UCI toolbox has a property called control name, which lets you give that control a custom friendly name to help you identify it.

This is very useful for organizing your controls in the layer window, and it's also a way that you can target that control using scripting, which I'll demonstrate a little later on.

If you were to add controls to your UCI from control panels without using the toolbox,

you'll notice those controls do not have a control name property.

But their preassigned name is still shown in the toolbox window.

You'll also likely notice the other major difference between these two controls now.

They all have a show hide checkbox, which lets you toggle them between visible and invisible,

and they all have a lock unlock checkbox, which prevents you from accidentally editing them after you're happy with their location.

But the toolbox controls have one more box.

The link box.

Currently, none of these controls are linked to anything, so they have a crossed out link icon.

In order to make these controls operable, you'll need to click on the link icon and find the control you want to link it to.

This list populates with all the components in your design, which might be pretty daunting in a larger design.

Being disciplined in naming your schematic pages,

separating content across different pages,

and giving your components custom code names could be the key to making the toolbox a worthwhile use of your time.

And do be careful because there's nothing preventing you from linking a text field to a mute button,

which probably isn't gonna be very helpful if you're not sure which control you want to link to.

Remember that you can hover your mouse over any control in emulation mode to learn its name.

Your UCI toolbox control isn't doing what you think it should be doing, you probably linked it to the wrong control in the schematic.

Either way, you'll see that the link icon changes to a completed chain link once it has been assigned apparent.

So keep an eye out for any unlinked controls if your UCI isn't behaving properly.

There's one graphic tool available in the UCI toolbox that isn't available in your right side pane.

It's called the Flex Box.

When you add a flex box to your UCI, it may look a lot like a group box,

but this is actually a dynamic container used for making quick work of auto arranging your controls.

For instance, it's pretty common when building UCI for you to have a number of similar buttons;

such as navigation buttons or source selection options for HDMI, routing, et cetera.

And you invariably end up spending a lot of time nudging those buttons around on your UCI and distributing them,

and the moment they're perfect is guaranteed to be the same moment that the client tells you that they need two more buttons they forgot to tell you about.

So sorry.

Thanks for your hard work, and don't worry, that's only gonna change 10 more times before you're done.

Well, instead of meticulously rearranging all your buttons, every time there's a change,

just drag all these controls into your flex box.

They will automatically rearrange themselves into a grid within the flex box,

and you'll see that the flex box is now an expandable item in your UCI editor window.

Much like a page or a layer.

In its properties, you can determine if you wanted to display its contents in a row or a column,

and whether or not that choice should wrap to create multiple rows and columns based on the size of the flex box.

You can adjust the gap between all the objects to space them out a bit, as well as choose the manner in which they are aligned within their rows and columns.

Veterans of CSS may recognize many of these terms because the flex box is essentially an HTML feature for displaying objects, which has been lifted into Q-SYS.

So yes, this can save you a lot of time when organizing your UCI since it automatically updates whenever you add or remove another item.

But the best part is that it does this automatic rearrangement.

While the design is running as well, in later trainings after Q-SYS level one,

you'll learn how you can programmatically change a controls visibility from true to false using custom coding.

Let's say you have a conference room with an HDMI cable.

A user could use to connect their laptop, but if there's no laptop connected,

I wanna hide that HDMI source as an available option on the UCI, so nobody selects it.

If those source selection buttons are in a flex box,

the remaining controls will automatically readjust to distribute the available options rather than presenting the user with an awkward gap where the button once was.

Now one last thing to talk about.

There's another tab in the UCI editor window called variables.

This is definitely a more advanced topic, but I don't wanna just gloss over it and pretend it's not there.

After all, if it was meant to be ignored, we would've named it Patrick's emails.

So, no, since we're talking about the toolkit, let's spend a little bit of time on this too.

This is a place where you can store variables, which could be applied to objects in your UCI, created by the toolkits.

However, doing so does require some Lua scripting, so I'm only gonna skim the surface of the topic here.

Here's an example.

Let's say there's a text field on your UCI that you may wanna change later on.

I'll add a read only text box and name it whenever I want: Mr. Texty.

Then I'll create a variable using the plus button and name it whenever I want to as well: Mr. Very.

I could then select the UCI script tab to write some code that would associate these together.

This is a Lua editor window where you can write any kind of code you want to govern your UCI,

and like I said, that's an advanced topic, so you don't need to follow along with me on this one.

Just watch.

I'm gonna say that the control Mr. Texty string, that's its text, basically is defined by the UCI variable, Mr. Vary string.

I'm actually gonna wrap that code into a function called: update Mr. Texty.

I will then run this function when the script first runs,

and I'll run it a second time whenever the UCI variable, Mr. Vary event handler is triggered,

which basically means that if anyone changes the variable, it will run this function and update the text.

So here I'll save this to the core and run.

And now when I change the variable, the text on my UCI updates, that's handy.

But the real power of UCI variables is that they can be accessed through the core manager, and by extension, Q-SYS Reflect.

So from anywhere in the world, an administrator with access to this core could update this variable, and the UCI would update accordingly.

Now, that may seem silly for just changing a word on the UCI, but this is just a basic example to show you what this tab does.

If writing Lua code was way too terrifying for you, don't worry.

There's no Lua in level one training.

But after you complete Q-SYS level one training, you should check out Control 1 0 1 and our control and UCI training series,

where the fundamentals and intermediate courses focus on building control automation that doesn't involve a single line of code.

On the other hand, if you're intrigued to see more Lua, you should take our advanced control in UCI training course,

which guides you through everything you need to know to write more complex script using amongst other things, these UCI variables.

Alright?

Hopefully your brains aren't fried, and again, there's no more scripting or UCI variables on the level one exam,

but you might wanna use some of what you learned about the UCI toolbox when building your UCIs.

Thanks for watching, and we'll see you next time.