Q Light Controller+

Hey guys,

I really don't know what was wrong with me when I wrote the first post on this problem yesterday - sorry! I'm trying to do it following the guidelines now:

I noticed a behaviour that is a bit strange for me and because I'm willing to understand how QLC+ basically works here is the question:
When adding a slider in the vc in level mode (for a HTP channel) + enabling the "monitoring" checkbox, I am not able to control it. It seems like there is a "0" value sent permanently, which causes the slider to jump to this value immediately (check the attached workspace file).
Could anyone please explain why this happens or where this "0" comes from?

Thank you and keep up the good work!

QLC+ 4.10.1[also noticed on latest sources] Qt4/5
Xubuntu 14.04, kernel version 3.13.11.8

I was assuming, since the channel is in HTP, the slider is always forcing it's value. When the slider is in monitoring mode, too, it kinda sets its own initial zero (kinda creates a feedback loop).

I'm not sure if this is normal mode of operation, but I guess it is. To circumvent, create a scene with the one slider you need at max value for the fixtures you want to set. Next, set the slider to "Playback" and select the scene you just created.

It seems to be the only way to set multiple resettable values to a HTP signal, on multiple fixtures, when you need both, maximum values at times (flashed scene) but also intermediate values from another source.

polemon wrote:I was assuming, since the channel is in HTP, the slider is always forcing it's value. When the slider is in monitoring mode, too, it kinda sets its own initial zero (kinda creates a feedback loop).

Me too.
Isn't this kind of a bug, is it?

polemon wrote: I'm not sure if this is normal mode of operation, but I guess it is. To circumvent, create a scene with the one slider you need at max value for the fixtures you want to set. Next, set the slider to "Playback" and select the scene you just created.

Of course that's possible, but in this way there isn't the possibility to enable some monitoring, because that's what I want to do.

Of course that's possible, but in this way there isn't the possibility to enable some monitoring, because that's what I want to do.

Yeah, but I guess it would entail redefining what a fader is.

Because here's the thing: Suppose you use the fader to set a value to the channel. At the same time, the slider is set to the value of the channel.
When you move the fader, it'll try to set itself to the value of the channel. In the real world, this would probably work with motorized faders, as you'd just have to overcome the initial resistance by the motor.

However, here's the problem with programatically changing such values:
Suppose your fader is at 0. The fader sends the value to the channel, at the same time the fader sets itself to 0, too, and everything is fine.
Now, some other application sets the channel value to 100. The fader will either first set it's own value to 0, or first set itself to 100, if it's motorized (I'm using the real world as an example now).
As soon as the slider would start moving, it would send the lower, intermediate values from 0 to 100 to the channel, set itself to the channel value, and stop moving.

So, things like that would either not work at all, be incredibly buggy, or would require some additional hackery to make it work - in the real world.

So I guess it could be considered standard mode of operation :/

But here's the thing: I really would like some sort of level indicator for the VC. Like a bar graph or something, also it would be great if faders had a little extra button accessible from the VC, wher I can switch the "motor" of the fader on or off - as in select dependency on the channel on or off.
Or maybe, as long as the slider is grabbed with the mouse, or on HID control, the "motor" should momentarily disengage. The Idea here, is that a VC is actually better than a standard console with motorized faders.

polemon wrote:

Of course that's possible, but in this way there isn't the possibility to enable some monitoring, because that's what I want to do.

Yeah, but I guess it would entail redefining what a fader is.

Because here's the thing: Suppose you use the fader to set a value to the channel. At the same time, the slider is set to the value of the channel.
When you move the fader, it'll try to set itself to the value of the channel. In the real world, this would probably work with motorized faders, as you'd just have to overcome the initial resistance by the motor.

However, here's the problem with programatically changing such values:
Suppose your fader is at 0. The fader sends the value to the channel, at the same time the fader sets itself to 0, too, and everything is fine.
Now, some other application sets the channel value to 100. The fader will either first set it's own value to 0, or first set itself to 100, if it's motorized (I'm using the real world as an example now).
As soon as the slider would start moving, it would send the lower, intermediate values from 0 to 100 to the channel, set itself to the channel value, and stop moving.

So, things like that would either not work at all, be incredibly buggy, or would require some additional hackery to make it work - in the real world.

So I guess it could be considered standard mode of operation :/

But here's the thing: I really would like some sort of level indicator for the VC. Like a bar graph or something, also it would be great if faders had a little extra button accessible from the VC, wher I can switch the "motor" of the fader on or off - as in select dependency on the channel on or off.
Or maybe, as long as the slider is grabbed with the mouse, or on HID control, the "motor" should momentarily disengage. The Idea here, is that a VC is actually better than a standard console with motorized faders.

Thanks for your answer - and sorry for the very late response.
So I think I got why this wont work with sliders for HTP channels in level mode - thank you for your detailed explanation!

Although doing this with LTP channels does not work either, yet, I think this thread is done so far.