RGB Matrix Fade In Timing

The issues found when using the Function Manager panel
Post Reply
CaptW
Posts: 2
Joined: Tue May 10, 2016 11:47 pm
Real Name:

Hey All,

First time using QLC+, and think it is great. It is just want I need for a project I'm working that will be ~1,500 pixels of RGB LED.

The issue I am having is with the 'Fade In' properties for a majority of the built-in patters for the RGB Matrix functions in 4.10.3a. Using the Fill Unfill pattern as our test patter, made up of a 1x# or #x1 array of LEDS. Fade-In = 0ms, Fade-Out = 0ms, Hold = 1ms.

Example 1) This functions exactly as you would expect, the first pixel turns on instantly, and promptly afterwards the 2nd pixel turns on instantly, followed by the 3rd until the end of the Matrix is illuminated. Once that point is reached, the 1st pixel turns off instantly, followed promptly by the second, and so on, the opposite of the turn on sequence.

Example 2) Changing the value for Fade-Out to 250ms, functions as I would expect. The pixels turn on exactly as before, once the matrix is illuminated the first pixel begins its 250ms fade out. 1ms after the fade out STARTS for pixel 1, the second pixel starts its fade out, and so on. Simplified to say, the fade out for each pixel starts at the same rate as it did in example 1.

Example 3) Keep Fade-Out set to 250ms, and increase Fade-In to 1s. Pixel 1 takes 1s to fade-in, once the fade is complete, Pixel 2 starts its 1s fade-in and so on. During the fade-out process, Pixel 1 starts its 250ms fade out, once it is complete there is a delay of approximately 750ms before pixel 2 starts its 250ms fade out and so on. The behavior I expected would be something similar to example 2, where the fade-ins start 1ms apart from each other, but each pixel takes 1s to fade in, and the fade-out behavior would be that of example 2.

This seems to be the behavior for most of the 'sequential pixel' patters, as I have no problem with the Even/Odd pattern, but that may be because it is a 2-step sequence.

Using the 'save this matrix to a sequence' may add some information:
Example 2 has Fade-In, Hold, Fade-Out, and Duration as follows, (null, 1ms, 250ms, 1ms); Example 1 is (1s, 1ms, 250ms, 1s1ms)
Should the duration should still be 1ms for the 'sequence version' of example 1?

Hope this all makes sense, please ask any questions if my examples/explanations aren't clear. I'm open to any suggestions to try and get the fade-ins to function properly.

Thank you
janosvitok
Posts: 1266
Joined: Mon Apr 13, 2015 7:05 am
Location: Bratislava, Slovakia
Real Name: Jano Svitok
Contact:

See diagram how timing in QLC+ works: viewtopic.php?f=12&t=9920&p=43442#p43442

Does it explain your problem?
OddSocks
Posts: 152
Joined: Tue Apr 14, 2015 11:33 am
Real Name: Tim Cullingworth

Hi Welcome to QLC+

Janosvitoks answer is what you are coming across and it took me a little time to get my head round. Another thing that I came across but haven’t looked in to massively is steps less than 5ms aren't right. A sequence with total duration of 2ms is not twice as slow as 1ms they are about the same. I think this is due to the internal clock in QLC+ but haven't looked very closely yet.

I am also playing with numbers of pixels and am in the process of learning how to build QLC+ so that I can dive into the code and try and get the matrix system to work better with lots of pixels. Eg. my new random fill script.
janosvitok
Posts: 1266
Joined: Mon Apr 13, 2015 7:05 am
Location: Bratislava, Slovakia
Real Name: Jano Svitok
Contact:

re: 1 ms:

DMX frame rate is <40 Hz, i.e. one frame per 25 ms. That means anything shorter with not have enough time to get to device and/or the device will not register it.
By default open USB devices emit frames at 30 Hz, i.e. one frame every 33 ms.

QLC+ processes data by default every 20 ms (http://qlcplus.org/docs/parameterstunin ... asterTimer default 50 Hz).
It is then passed to output plugins that send it out independently (see above).

So more or less it doesn't make sense to use as low numbers as you do (there are exceptions of course).
OddSocks
Posts: 152
Joined: Tue Apr 14, 2015 11:33 am
Real Name: Tim Cullingworth

I know what you mean Janosvitok and I haven't yet done a thorough investigation in to how the timings are working, or the limitations.

Some of us who are using stupid numbers of LEDs ( my controller will control 5440 ) are using artnet or E1.31, so DMX framerates become less meaningful, and when filling a panel of 170 LEDs or more even 10ms takes 1.7s to fill.

Now I know this is a bit specialised, and I am not expecting the development team to leap in to action, it was just an observation and one I am planing to look in to at some point. It might be that if I adjust the master timer I can change things a bit, but it is so low on my list I haven't got round to it yet, I was mentioning it more to flag it up for CaptW who stated he was using 1ms timings.
CaptW
Posts: 2
Joined: Tue May 10, 2016 11:47 pm
Real Name:

Thanks to both Janosvitok and OddSocks for the quick responses.

The timing graph explains it in an easier and simpler way then I feel like i did! (Pictures are worth a thousand words, I guess?) Now knowing this, I can let the Lighting Designer for the project know so we can account for how QLC+ handles the timing and make the most of it.

Is there any way to 'hack' around this by using the 'save matrix to a sequence' and altering the duration there? Or do things just start to get weird and its not worth the hassle?

In the same boat as OddSocks when it comes to a stupid number of LEDs and using ArtNet/E1.31, but good to know about timing. 1ms was the first option after 0ms, which is why it was selected for testing. But I will be sure to use a more reasonable number in the future.
Post Reply