variables in light cues

[Alexandre Burton]

hello!

considering the QLab lighting command language supports proportional pulls such as

10 = cue A * .5

is there a way to connect the .5 above to a form of variable that can be controlled externally, either via MIDI or OSC?

thanks,

alex.

[Sam Kusnetz]

No, but you can already directly control 10 vis MIDI or OSC, so I’m not clear on how you would use this.

Can you say more about it?

Sam

—

Sam Kusnetz (he/him) | Figure 53

s...@figure53.com

[Alexandre Burton]

yes: we are building a multi-zone installation which non-linearly recalls morsels of scenes (in the above, cue A would comprise more than 1 channel, but only a subset of fixtures, and in parallel 4 or 5 other such ensembles would operate), which can be "affected" differently based on external considerations. the interactive logic is handled in another program, which could drive individual channels, but the aim is to maintain the light design inside QLab (where the LD can tweak to her liking (and add/remove instruments to/from cues and palettes), and also assemble different light commands in the actual cue, without leaving QLab).

so to be clear, the above example was a simply copy-paste from the QLab docs, but the LD might build an actual cue such as:

10 = cue A * ${x}

11 = cue B * ${y}

21-22 = 100

101 = 33

// etc

subcontrollers almost made it with their MIDI-controllability, but changing the sub controller immediately re-emits the whole sub controller elements, which is a different behaviour than pulling which can be selective and handled with a light fade. perhaps we could split the "conventional" cues components from the "interactive" ones, and driving the interactivity as subcontrollers, but we'd like to avoid that split and give as much creative control and autonomy as possible to the LD.

the other approach would be to use AppleScript to rewrite the cueText, but it's not evident to find a way to dynamically detect the presence of "variables" especially once the initial cue is re-written (or perhaps a cue can be somehow saved, re-written by changing the ${...} to some values, re-called, and restored to it's "template" form? would the performance/stability of such repeated operations be "safe" within QLab?)

thanks!

alex.