Controlling Procedural and Physical Modelling Plug-Ins

Turbine Parameter Feedback.

When Qlab is controlling its own internal parameters, it is trivial for it to find the current values of controls and adjust accordingly. This is why a fade can interrupt another fade and take over seamlessly at the current value of the fade’s target e.g an audio level, a video geometry parameter etc.

In this example audio fades, up and down, are fired before the previous fade has completed.

With MIDI and OSC fades QLab does not know what device is receiving this data, and therefore specifies the beginning and end points of a fade within a single cue. Here’s what happens in Turbine when we execute cues at arbitrary times.

The first time the thrust parameter is increased it goes to maximum, and as that is the starting point of the down fade the action is seamless. In the second example the down fade is triggered before the up has completed, and because each cue contains the start and the end point as absolute values, there is a discontinuity.

If QLab is controlling parameters in an external program it has no way of knowing the current level of the control, particularly as it may not be the only controller using the plug-in. For instance, using the Turbine Plug-in we might start the engine noise during a scene change and ramp it to a certain level, using QLab, before an actor takes over control with flight controls e.g. a control column and 2 pedals which are wired to produce MIDI or OSC data to control the plugin. In the middle of the scene, the actor is shot and we take over the control of Turbine, and simulate an accelerating nose-dive under QLab control.

In order to take over seamlessly, QLab needs to know the current value of all the relevant plug-in parameters and set the start point of any MIDI or OSC fades at the current parameter values of the external plug-in.

In order to do this, we need Turbine to tell QLab the value of any controls we are using every time they are moved, either by MIDI  from QLab, manually within the plug-ins own interface, or by external MIDI or OSC controllers. QLab needs to store these values somewhere, and at the point, a MIDI fade is executed, set the start value for that fade to the value it has currently stored for that parameter.

Parameter Feedback

For any control that we want TURBINE to keep QLab updated with its value, we can use something similar to this Bidule patch.

Thrust Feedback

A variable  named for the parameter it is linked to (in this case Thrust) is linked in the parameter page like this:

thrustlink

This is a connected to a change block which sends a positive output trigger every time the value of the variable rises (+1) or a negative trigger every time the value falls (-1).

As we want to send the change regardless of the direction of travel we follow this with an abs (x) function block so that both values produce a positive trigger.

We send this trigger  to an OSC message creator which contains an OSC address, in this case

/cue/9002/translationY

It adds the argument from the value of the variable Thrust Pos Feedback, and when it receives a trigger signal will output

/cue/9002/translationY 1436
(or whatever the current value of the thrust slider position is)

This tells QLab to set the Y translation of cue 9002 to 1436,  thus storing the variable where QLab can easily access it.

Cue 9002 lives in a QLab cue list created to store any variables fed back from the external plug-in.

Cue9002

As you can see cue 9002 is a disarmed text cue. These are ideal for storing variables as they will not be marked with a red cross (error flag) even though they are dummies, as they don’t need a target, as a video cue would, and in the geometry tab there are 4 parameters that will store floats, 3 that will store integers and a notes field that will store strings. In this case, the value 1436 has been stored in translation Y as the current value of the Turbine thrust slider.

When we want to use this value as the start point of a MIDI fade, to move the Turbine Thrust Slider to a new position, we use this piece of programming

ThrustGroup

A ‘fire all children group’ contains a network cue which queries the translationY value of cue 9002 (where our variable is stored) and sets the  cue MDOWN’s fade start value to that value. Cue MDOWN is then triggered moving the thrust slider from its current position to the value specified in the ‘fade to’  field of the cue. (Ignore the fact that these values are labeled velocity, they are pitch bend values.)

If we repeat this program structure for other MIDI fades e.g faster fades, fades in the opposite direction etc. we will have a set of group cues that can be triggered in an arbitrary order, with seamless transitions from one to another.

There is an almost identical bidule structure which sends the slider position to cue 9001 Y Translation but scaled to move a fader top graphic in QLab in pixels.

fadertop scaling

Cue 9001 is not a dummy cue, but is an actual video cue targeting the fader top graphic file and moving its y translation with the values generated by the thrust slider in Turbine.


MenuGraphic