Q Light Controller+

Hey, I am currently working on a setup for a small film studio. In this studio we use Unreal engine (ArtNet) to control the DMX lighting. But sometimes a gaffer wants to overwrite these values. So, we give the gaffer his own Midi interface. I would like to be able to blend these two value's depending on another factor. A so called Lerp function. How can I make a setup in QLC+ that does this?

Can you pass the MIDI values to Unreal Engine and do the computation there?

In QLC+ it would most probably involve a bunch of submasters, loopback channels and what not

Jano

Hey Jarno,
That is an option. But not the preferred one since that means having to build in the computation code into every Unreal project separately.

It's a simple artnet merge. Look into the Passthrough functionality of a universe.

It's not simple merge. The devil is in the LERP function - the third fader is cross fader between Unreal and gaffer.

If I understood correctly, OP wants to do (let's say the values are 0-1 or 0% to 100%):

output = crossfader * unreal input + (1-crossfader) * midi input

I was thinking about two sets of sliders in a frame with submaster and one loopback slider that control one submaster directly, and the other in reverse mode.
The problem is the addition vs HTP. My idea won't get above 50% when crossfader is in the middle.
Only place I know of where addition is possible is RGB Matrix blendmode, but I didn't come up with any idea how to use it.

Jano

i was thinking about the same, here is what i came up with yesterday:



It starts with 2 sliders controlling the same channel, each in its own frame together with a submaster.
Each submaster has a loopback channel as External controller.
Each Loopback channel is set by a scene.
Two scenes are added to a chaser that is set up for "crossfader".

Because you don't want the crossfader to "flip the scenes" when it reaches 0 or 255, i put a Loopback fader on it, that is limited to range 2 - 253.

As it is not possible to put a submaster on a submaster (nesting), i used a RGB matrix with Pattern = Plain and Blend mode = Subtract to control the Output.
To make it look like the others, set the slider to Reverse.


While testing i noticed that (while crossfading) you can get DMX values that are lower than the lowest value of the 2 sliders (if you set slider 1 = 100 and slider 2 = 200, you get values under 100).
By using a Logarithmic Deep Channel Modifier i came close (though it is not a LERP function).
As i am never going to use this logic myself, i did not feel the need to spend more time on Fine Tuning this Channel Modifier.

Remark: don't forget to press play to start the chaser (you could also add this to your Start Up Function).

Here's my proposal, derived from Michel's, this seems to do just what's been asked for: the lower knob is inverted in direction, gets controlled by the upper knob and controls the right frame's submaster. the channel faders in the frame set the same channel intensities, and the final output is the interpolated value.
The lower knob (Aux Fader) acts independently on the right submaster, so that is an additional possibility to just override the left frame's output (if the right one has a higher value only though, in HTP mode).

Funny, for me it all started with the idea to use a crossfader (from a cue list) for this. I build my "entire construction" around it.
And now it turns out, that that is just the part that can be missed.
Clever thinking, Edgar.


Today i did a bit off testing (it was raining all day overhere).

Case 1.
Set the first slider to 200 and the second slider to 255.
If you move the Crossfader from value 000 to 055, you get the expected result (DMX lowers from 255 to 200).
But if you continu moving the crossfader from 056 to 143 the DMX value drops to 112 and then from 144 to 255 it will raise again to 200.

Case 2.
Set the first slider to 255 and the second slider to 200 (the opposite of case 1).
If you move the Crossfader from value 255 to 200, you get the expected result (DMX lowers from 255 to 200).
But if you continu moving the crossfader from 199 to 111 the DMX value drops to 112 and then from 110 to 000 it will raise again to 200.

Case 3.
Set the first slider to 100 and the second slider to 255.
If you move the Crossfader from value 000 to 154, you get the expected result (DMX lowers from 255 to 100).
But if you continu moving the crossfader from 155 to 183 the DMX value drops to 072 and then from 156 to 255 it will raise again to 100.

Case 4.
Set the first slider to 255 and the second slider to 100 (the opposite of case 3).
If you move the Crossfader from value 255 to 100, you get the expected result (DMX lowers from 255 to 100).
But if you continu moving the crossfader from 099 to 071 the DMX value drops to 072 and then from 071 to 000 it will raise again to 100.


From that i learned that, with using a channel modifier (like Logarithmic Deep) you maybe can prevent the DMX output value from dropping (more than a bit) under the lowest of the two slider values, but you will end up with an "unpredictable dimming curve".
If slider 1 has a lower value than Slider 2, the action of the crossfader is in the beginning of the DMX range (000 - approx. 127) and the last part does not contribute anything.
If slider 1 has a higher value than Slider 2, the action of the crossfader is at the end of the DMX range (approx. 128 - 255) and the first part does not contribute anything.


Sorry to say, but this is far from the "LERP function" that Thijs is looking for.

Oh my bad, as usual I didn't test the output well enough to notice the drops you observed...

In my opinion this is a mistake in computation, a bug and not something we should accept to happen.

I remember manufacturers advertising their hardware desks with terms like "dipless crossfade".

It reminds me of a similar problem I had years ago (when we still had a double cuelist side crossfader) with manually crossfading in the cuelist when a channel had the same value in both scenes, hitting "next cue" would do a smooth transition, but pulling the fader would show a intensity dip around 50 percent of the fade. i remember that at some point Massimo fixed that level dropping by applying a different blend mode (BlendedCrossfade) on cuelists when not in step mode.

I admit that after many years of trying I still have trouble understanding the underlying source code, See

https://github.com/mcallegari/qlcplus/b ... ser.h#L221
https://github.com/mcallegari/qlcplus/b ... r.cpp#L535
and for v4
https://github.com/mcallegari/qlcplus/b ... .cpp#L1027

I'm not sure how (or if at all) this can be applied in this case. In fact I'm hesitant commenting about it at all, as I feel I'm missing essential basics when reading the engine code of QLC+.

And again, sorry for not noticing the level drops in my proposal.

It's not a bug.
Keep in mind that we are not actualy using the fader logic of QLC, we are only trying to achieve something simular by using 2 submasters.
In my solution i only used the Crossfader Logic in an attempt to make those 2 submasters work together.

If you look at it in a different way, you could say that we are trying to solve two problems with one solution:
- the problem that the gaffer wants a higher value.
- the problem that the gaffer wants a lower value.
If we can split it up, it might be easier to solve.

In fact we we don't even know what the actual problem is, that Thijs (the Opp) wants to solve.
As he runs a small studio, he probably also has a small budget. It could be that he has to work with Fixtures of different makes and he cannot get the dimming curves to match.
It might even be that he is not happy with the Gaffer, and hopes to find a compromise in their relation by adding this logic (specifically the blend between input 1 and input 2).

I suggest we wait for his reaction.

Thanks everyone for the responses. Since I want to keep things simple, I decided to do the commuting and the lerp function inside the unreal engine. I receive the the gaffers DMX signal and send it via ArtNet to the engine. Here I combine the different signals and send them back to QLC. For me, this was the quickest solution.

But it remains a nice question to do this in QLC natively.
The main issue is combining multiple values using mathematical rules. Mostly the lerp function. It's sad to see that there isn't any easy solution to this.