Concepts

Concept	Description
Device	An external application or piece of hardware that can be controlled by CueConductor, or can control CueConductor
Sink	An external device that can be controlled by CueConductor
Source	An external device that can control CueConductor
Driver	Code written to interface CueConductor with a sink or source device
Action	An instance of a single sink being put into a certain state, scene, cue or preset
Cue	A moment in time at which one or more actions are fired
Tracking	The idea that not every sink will be affected by every cue
Show	A list of cues that make up an entire performance

Sinks

Sinks are the basis of outgoing show control data. They’re called sinks because they take data away from CueConductor, just as a sink takes water away. A sink can be anything that can take data over the network or MIDI, including sound and lighting consoles, effect processors, playback applications, and more.

Sources

Sources are the way other devices can control CueConductor. Sources take network data or OSC in, and use it to fire cues within CueConductor. A common use case for this is having CueConductor “chase” another cuelist, such as your console cuelist. This means CueConductor will constantly be kept in sync with your console cues, without you needing to set up a separate automation or have multiple “go” buttons.

Drivers

Drivers are a fairly technical concept, but they’re included here for completeness. A driver is a piece of code that’s written to interface CueConductor with external devices. CueConductor has several device-specific drivers (such as those for QLab and DiGiCo consoles), but also has two generic ones: OSC and MIDI.

Generic sink drivers allow you (to a certain extent) to customise how data is sent from CueConductor, opening up the potential to integrate with more niche devices without needing a device-specific driver. See their respective documentation pages for more information, but there are some limitations to this. If generic drivers are not enough, reach out to us with documentation regarding your device’s show control protocol and we’ll look into getting a driver written up.

Actions

Actions are where cues and sinks come together. They’re a single cell in the cuelist table, and define what data should be sent to sinks and when. For the most part, they’re an abstraction over cues that you won’t need to worry about, but being aware of their existence can help understand things like tracking.

Cues

A cue is a moment in time within your show at which something needs to change. You might have a cue for every song or scene, or multiple cues per song. How you program your cues is up to you, but regardless, a cue should be an indication that some setting, somewhere, is changing.

Did you know?

The current (2024-25) Australian primary production of Wicked have a cue called “Clock Tick Cue” that does absolutely nothing. It is therefore extremely important that it is fired precisely after Glinda says “tick tock!”

When using an external source to control CueConductor you may not necessarily want every cue to actually effect something. This is extremely easy with tracking (see below), and provides as much information to the operator as any other cue. Understanding that a given cue only affects the device that it is fired on is just as important as understanding when other devices are affected.

Tracking

Tracking is the idea that while not every cue changes the state of every device in your system, there’s a good chance that those unaffected devices are still being used to process something in their most recently recalled state. It’s important that our cuelists can understand this, otherwise we might need to end up duplicating data that we don’t want to (and needing to update both copies anytime something changes). CueConductor represents tracked values by partially greying them out, indicating that while the value is still live, it has not been recalled in a given cue.

We deviate slightly from this convention with a feature called Jump Assist. When this is enabled on both the entire showfile and a given sink, CueConductor will re-trigger scenes on external devices if they don’t match the last recalled scene, even if those values are tracked.

Take, for example, the below cuelist. In this example we have a DiGiCo SD7, a single TC System 6000 engine, and QLab for playback.

There are a few things going on here. First, tracking is enabled on the SD7 and FX engine but disabled on QLab. This is something that’s been done deliberately in this showfile because QLab is presumably being used for sound effects, which are triggered in a certain cue and are not a “scene” that gets tracked.

You’ll also notice how tracking works in this example cuelist. In cue 2, the only device being triggered is QLab - both the SD7 and FX engine remain in the same scene. This unifies the cuelist, as you can control external devices individually without the need to create a new cue in other devices.

Finally, this can be used as an example of how jump assist can be useful. Say, for example, you’re in a rehearsal and for some reason you need to skip from cue 4 back to cue 2. If it’s enabled, jump assist will re-send the tracked values to the SD7 and FX engine, ensuring all your devices are in their correct states for that scene.