QLab 4 – Lighting Workflow Ideas

Following the release of QLab 4, On Stage Lighting presents some suggestions for lighting workflows aimed at users who may be unfamiliar with programming QLab and its core concepts.

So, QLab now contains a lighting control interface plus Art-Net output capabilities. This has great potential, but what if you know lighting control but have never programmed QLab?  Today, I’ll going to run through a few potential steps to programming the lighting system for a show using QLab only and not relying on external triggering of your favourite lighting console via MIDI or OSC.

Let’s be clear, QLab lighting control has been released as what you might call the MVP – Minimum Viable Product. This means that if you are expecting all your favourite tools and workflows from the Grand Hog Titan Ti, you are going to be disappointed. At least for now. Instead, lets look at what we could do in programming and cueing and relate some of those things to conventional lighting programming practices. The current QLab lighting functions are best suited to control of generic single channel entities such as dimmers or some basic colour mixing fixed units like LED wash lights. Don’t expect to have an easy time controlling complex moving lights just yet. Lets say you have a theatre stacked show with 96 dimmers and some LED RGBA units and go from there.

Setting up the lighting control in QLab

Instead of rehearsing the user manual, I’m not going to walk you through patching fixtures, labelling or getting Art-Net working. There is info on that at Figure 53. Suffice to say, you can patch up your dimmers and LEDs.

You can also create Groups. This is important, even in a basic lighting control interface, and reduces the amount of effort it takes to select lots of fixtures at once. In QLab 4, I would advise relying heavily on Groups and even put specials in Groups of 1 fixture if you need to. Selecting groups, either via the screen or by entering a name/label, is going to be a lot more user friendly than typing in long winded command line arrays of channel numbers.

Don’t get lighting groups confused with the QLab Group Cue, which is another important feature that I’ll explain in a lighting control context later.

Selecting lighting groups is easy in the Light Dashboard. I prefer the Tiles and drag interface rather than the Sliders. I’m more likely to use this interactive interface, rather than command line which is obviously a familiar way of working to many theatre users but I find even the best command line interfaces less intuitive than an interactive select/adjust method. The lighting Groups interface does currently get rather busy, particularly when you add in colour mixing kit.

Multiple Cue Lists

QLab deals in multiple cue lists already for any cue, not just lighting. You can make different cue lists of just lighting cues if you like. You can also fire different cue lists or parts of lists from other lists – just like a console only with no writing special macros.

Palettes in QLab

At the time of writing, there is no specific palette functionality in QLab 4. Although not a deal breaker for getting light on stage, this does make dealing with colour mixing less friendly than most lighting controls. It also means no Intensity palettes, something that even our show with no moving lights, could benefit from.

There is kind of way to work around this, but it isn’t a direct palette equivalence. One option is to create a Cue List or Cue Cart of ‘base’ values that are then fired as part of another lighting state using what I’d call the Play Cue (I think it’s called Start, actually). This doesn’t make a real palette as the cue timings are taken from the original cue. However, it is a way to incorporate a centrally created look into another cue.  Some form of palette is surely a must for future releases. (Along with a better colour mixing interface).

Disarm and other tools

One function that is really useful in QLab and can equally apply in lighting cues is being able to disable a cue without deleting it. Not only does this give an obvious advantage during rehearsal and programming, but top level QLab programmers use Disarm as part of complex conditional or Loop cue sequences.

How about flagging a cue that needs further attention?  Easy, on the left end of the cue list.  Add notes, not a problem.

If you like your programming really geeky, how about checking out the Script cue?

These and other cueing features is where QLab excels, why not see how you could use them for lighting too?

Fancy Paste

Being able to copy and paste certain elements of cues such as time or levels is a lighting control standard. There is scope here for copying stuff to multiple cues and reducing some of the spade work.

Building Lighting States

The most basic workflow, like any lighting control, is to set lighting levels and record them as a single cue. This is then given a fade time. However, I suggest thinking a little more about how each look is built before you start filling a cue with levels and I’ll explain how and why next.

To make a cue of any complexity, start with a Group Cue. In QLab, a Group Cue is a container for other cues that can also be targeted by other cue actions. Once you have an empty group cue, think about the lighting elements you’ll be using in the look – lighting groups in particular. Instead of making a single cue, make a cue for each group or element inside the Group Cue. To make the whole look happen at once, set the Group Cue to Fire All Children Simultaneously. Why do this?

The power in QLab is being able to set different fade and wait times to an individual cue. In creating a Group cue of different parts of the lighting rig, we have left scope for complex fade times and what some consoles would call Part Cues. It also gives us the option to split the Up / Down times in a way that a standard ‘everything happening’ cue doesn’t.

This takes a little more thought before building the cue than conventional lighting programming, which usually leaves these nuances until after the whole look is built. This solution isn’t ideal for creating per fixture wait times on large numbers of channels but remember we are looking a theatre stacked show here. 90% of the time, we are simple looking to nuance the Up/Down and Part Cue timings. With these individual cues-within-a-cue, we can also easily change the firing order and tweak the way that the full look arrives on stage.

Cue Timing

As with sound and video fades, a QLab Action time is equivalent to the crossfade time in conventional lighting control.

Follow Ons

QLab has always done follow ons easily, with either Auto-Continue or Auto-Follow. Simple set your Pre-Wait and/or Post-Wait times according to taste.  Use along with Groups and Start Cues for further fine tuning

Blackouts

Because QLab lighting cues just track by default and therefore behave in a LTP manner, creating a blackout is best achieved what we’d call a Hard Block blackout: A cue that sets all your channels to Intensity = 0. Also, the software doesn’t have stuff like a Grand Master output control, so being able to black the rig out needs a recorded cue even if it’s stashed in a list of tool cues along with the rig check etc. Create with the All lighting group at 0.

Chases and FX

Intensity chases are easily programmed using Group and Loop cues.  Intensity FX, or any FX, in the conventional lighting programming sense, are not directly available.  Yet.

Conclusion

This guide was written for those in lighting who may not be familiar with QLab at all. If you are familiar with the audio and video tools, would you bet against Figure 53s ability to make a highly functional set of tools and a high level of usability? Who knows what the future will bring but I’m not gonna rule out QLab in the lighting control space just yet.

Let’s not pretend that lighting control in QLab 4 is perfect, there are both niggles and big holes in the current functions and workflow for those used to lighting control reality.

I have no specific news on this, but I imagine that this is just the start for Figure 53 and their journey into lighting control. I’ll be continuing to research the reality of using a software that I already know in sound and video programming, in a new lighting control context that I’m also well versed in.  Will keep you posted.