Q Light Controller+

Hi,
I have a problem with RGB Colors with Star-light mini wash led (that one: https://sourceforge.net/p/qlcplus/discu ... d/b52d1798 )

the issue is to give a scene with a color to all devices.
the first one keep color only first time, and after all RGB values in Device monitor apperas at 255 for the first device (i generally use 4 or 8).
that devices have RGB inverted and i have used channel modifiers to adjust it.

i attach my workspace and a video that show that issue

Tolmino,

you indeed have found a bug. The modifiers are applied too soon in the code. They are applied before HTP check and before Grand Master, but they should be applied at the very end of the processing chain.

Until somebody fixes the code (and releases new version), you can make it work by removing line 9,10,11 in the qxw file (in the LED 1 fixture definition).

Thank you Jano, i'm using Git version, so as soon you write a solution into sources, i can try.
thanks in advance

At this point i'd like to add that this fix is needed for another reason, atleast it sounds for me like this would solve the problem:

When inverting a channel on a Pan or Tilt channel of a moving head it works well when using the X/Y Pad. But if you have sequencesteps that you want to fade these inverted pan/tilt channels in it seems that QLC forgets that the channel is inverted. Instead it starts to fade from the uninverted value.

E.g a sequence ends with pan on 0 wich is 255 by invertion. When launching a sequencestep with 127 it does not fade from 255, instead it fades from 0.

Is this the solution, to apply the modifiers later?

please, Jano Svitok, can add that modifier into resources/modifierstemplates ??

Tolmino,

you forgot to change the name. I did it for you, but the template doesn't load correctly for some reason (it looks like the points are on y=255-x line). I need to debug it.

Hi Jano.
i have got a look at source code into

https://github.com/mcallegari/qlcplus/b ... iverse.cpp

and in line 500-501 is applied the channel modifier.
it is still applied before HTP and Grand master... how can we put that code too at the very end of the chain ?

There is a way that can i help you ??

It should work if you move lines 500-501 between lines 521 and 522, and also between lines 547 and 548. To make sure it works (except that you compile it and run) some tests would be nice - see https://github.com/mcallegari/qlcplus/b ... e_test.cpp add a new method like

void Universe_Test::channelModifiers()

set some channel modifier for a channel, and verify that the values are as expected.
For more bonus points create one test that will use writeRelative and one that will change grand master.

For help writing tests see qt-project.org/doc/qt-4.8/qtestlib-manual.html and http://qt-project.org/doc/qt-4.8/qtestl ... rial1.html

test are run either by running ./unittest.sh in the main directory, or by running ./test.sh in the engine/test/universe directory

Channel modifiers are applied before HTP check and Grand Master on purpose.
Please **DO NOT** change this logic in the code until this discussion explains why it is necessary.

The concept of a modifier is:
I want to change how a fixture channel behaves. It's like changing the firmware of the fixture itself. So all the other modifications (HTP and GM) must be performed AFTER the starting behaviour.

"It's like changing the firmware of the fixture itself."

Then shouldn't the channel modifier be applied after the very last step ?

It depends on how you look at the modifiers.

If the purpose is to limit the output values, the modifiers should be applied at the very end of the chain, to make sure that the output value falls in the range. If you apply the modifiers before GM, the final value may be outsidet the range.

If the purpose is to invert the channel (e.g. because the dimmer channel @ 0 means full, and @ 255 means off and you want QLC+ controls work in "normal" fashion), then if you apply the modifier before HTP check, the HTP check will not work (because the values are already inverted).

If the purpose is to adjust curves, still applying GM to adjusted data may not be the desired effect.

I believe the channel modifiers should be the lowest layer more or less transparent to the rest of the QLC+ (except DMX monitor which should display the data after modifiers, i.e. as they are output to cable).

Nope. Leave channel modifiers aside for a moment.
If Tolmino's fixture was born with inverted DMX values, you would apply HTP and GM **after** the original value you would like to send to the fixture.

Does this make sense ?

GM simply apply a scale from 0.0 to 1.0, so a modified DMX value can never exceed 255.

As for HTP check, the inner "problem" is that QLC+ considers instensity at 100% when DMX value is 255. Obvsiously if your light is 100% when DMX value is 0, the whole HTP logic gets broken.

GM: 0.0 to 1.0 still breaks the case when I want to set minimum output value ("preheat"). If I set channel modifier to translate evrything to interval 5%-100% (i.e. minimum value is 5%) than GM could still make it down to 0%.


HTP: You are right. Inside QLC+, 0% intensity (off) is represented by value 0; 100% intensity (full on) is 255 and HTP means Highest [intensity] takes precedence.

If modifiers are not used at all, the fixture intensity is inverted.

If modifiers are used before HTP check, it gets broken (it is lowest intensity takes precedence in this case).

If modifiers are used AFTER HTP check, everything works fine.


It is like QLC+ talks one language, all computation are done that language, and after everything is done, the value is translated to different fixture language.
Or, let's say QLC+ uses metric system, and fixture uses imperial. The translation should be done as the very last step.

I confirm what I said: modifiers acts at the beginning of the chain on purpose.
When I implemented them, I had in mind chinese lights where LEDs intensity is not linear.
So basically you apply an exponential modifier to make them linear. In this case you will still need the possibility to "scale" the intensity with the GM and to overlap different scenes with the HTP check.

For the inverted modifier I had in mind Pan and Tilt channels. Not intensity.

We can move them after the HTP check, but not after the GM.

Sorry, but I have to agree with Jano and David on this one

If you were to take a soldering iron to Tolmino's fixture so that RGB values were no longer inverted the problem would be solved. This change would be to the last link in the processing chain after qlc had sent the DMX down the cable. This is equivalent to qlc modifying the channel values as the last step in its processing chain before sending out the DMX.

The same line of reasoning applies to modifying the hardware or firmware of “Chinese” fixtures so that they fade linearly.

Tolmino's problem is not one that most of us will need to deal with since:

1) Inversion clearly messes up HTP, fade in and out from and to zero, submasters and the GM if applied before them, but this doesn't cause a problem in most cases because inversion is mostly used for LTP such as pan and tilt.

2) Cross fades will work correctly with inversion applied before or after them since the fade is occurring between 2 specified values.

3) HTP continues to work correctly after a non-linear modifier if the modified values increase continuously as the original values increase. It unlikely to give desirable results if you set the channel modifier in a series of peaks and troughs.

4) The effects of a non-linear modifier are often fairly subtle, but, however, if non-linear modification is applied before a linear process such as cross fading between scenes, the start and finish values will be correct but the intermediate values will lie on a straight line and not on the correction curve.

A similar consideration applies to the action of the GM and submasters. If, for example, you move them from full to half, the output for a non-linear intensity channel needs to be modified to something other than half its previous value.


Additional point:

It would be quite useful if the DMX monitor could be set to show either DMX values before modifiers were applied (for analysing how one's programming is working in a project without being connected to fixtures) or DMX values post modifiers (for troubleshooting problems with fixtures).

Hi.
can i ask a working solution?
Massimo, Jano what is right way?

Hi Guys
i have made some test in engine/src/universe.cpp moving channel modifiers code from line 505 to two different places:
after "if {m_preGMValues"
and after "if {m_relativeValues"
where is now

something is changed.....
i have a stable qlcplus too (i have used it for 2 hours and all is working fine, with different kind of lights)

the machine with RGB inverter channels (the mini wash Led 3W) do something different:
i'm using same qxf file i have sent in that thread
so the machine with lower DMX start address is affected by a strange dmx error (before i touch code, i had all RGB channels to 255 that means a machine with no light.... now it has all 0 so do light even, with all color scene and with all animations. when dimmer is up, it gove a full White RGB light )
and all the other mini wash led 3W machines works fine using color scene.
but animations have a different working status:
if i set a fill/unfill animation with red color, red in dmx monitor go up and down as expected.... but Green and Blue has a 0 value (must be 255 because inverted) so are emitting light when i don't need....

there is any test i can do ?

I believe lines 505 and 506 should go between 533 and 534 (after applyGM). Note that I didn't test this idea, it's up to you
As why the animation didn't work - can you post your current qxw file?

Hi Jano

i'm using the same qxw i have sent in that post.
without any mod.

there is something in the code that don't permit normal work of rgb channels of first Wash led.