Q Light Controller+

There's a glitch in the matrix!

I've been working on an update to the Plasma RGB Script, and ran into some behavior that I wasn't sure was coming from the script or from QLC+ itself. I've recreated the behavior with a different built-in script, so I'm pretty sure now that it's a bug in QLC+. I've taken a quick peek at the source code, and am not quite able to track it down yet.

Here's the behavior: When an RGB Matrix has to fade all three color channels, the Green and Blue channels will jump between steps instead of honoring the Fade-In/Fade-Out times. But only when having to crossfade between 100% settings across channels. For example, when fading between RGB(255,255,255) and RGB(255,0,0), the Green and Blue channels will jump instead of fade at the fade times. But when going between RGB(248,255,255) and RGB(255,0,0), the fade times are honored correctly.

Please see the attached workspace for examples of working and non-working combinations. If someone more knowledgeable of the source code could point me in the right areas and directions to look, I don't mind digging into this myself. I just wasn't coming up with where the problem might be.

Hi, just a quick question, which OS and QLC+ version?

Have had a bit of a look and play using Linux and QLC 9.4.1

It appears that if a new RGB matrix step is started and there is no change on a channel the the fade jumps ahead in time. This only affects the following channels in a RGB fixture. So red affects green and blue, but green only affects blue.

If you look at the attached file and blue jumps function, you will notice red fade is fine but blue jumps. if you take the final value of the green channel more than 50 less than the start value the jumping will stop. The value of 50 is due to there being 50 elements to the matrix.

I think the problem might be in rgbmatrix.cpp but I am no expert in this

OS: Win7 64 bit, WinXP
QLC+ 4.9.1

Thanks for looking, Tim. Your observation is pretty much what I was coming up with for an explanation of the behavior. The 'jumps' only occur on 'downstream' colors, and only when the 'upstream' color starting and ending values are close to each other. In my test it ended up being at least a difference of 8 to make the jumping go away. But then, I had exactly 8 elements in my matrix as well.

Thanks for the details, there's an issue indeed

Fix incoming...

EDIT- Fixed in GIT

Bloody hell guys that was fast

This is what I love about open source. If this was one of the big software houses we might have just about got an e-mail saying they had revived our message

It's just that David can't sleep well at night if he knows there are bugs in QLC+ Just kidding of course

Fast is good but it's also the cause of regressions sometimes and we realize them only when a new release is out. (not saying this is the case)
That's why I try as much as I can to produce TEST versions where there are new fixes or features

But yeah, if you build from sources, it's almost a real-time evolving software

Awesome work, David! Thanks for the quick turnaround. I've compiled and tested here, and the colors fade smoothly now.

It's just that David can't sleep well at night if he knows there are bugs in QLC+ Just kidding of course

The regression was my fault, so I HAD to fix it!

Fast is good but it's also the cause of regressions sometimes and we realize them only when a new release is out. (not saying this is the case)

It was caused by the fix of another bug I only tested the previous change with the red color, so I didn't catch the regression.

That's why I try as much as I can to produce TEST versions where there are new fixes or features

Yes, and that's why QLC+ needs more people to test the TEST versions with a lot of different cases!

plugz wrote:

It's just that David can't sleep well at night if he knows there are bugs in QLC+ Just kidding of course

The regression was my fault, so I HAD to fix it!

Ouch, I didn't know about this regression actually
Well done then in fixing it