16 bit pan and tilt

[Russ]

Hi, I have been using QLC+ for just under a year to control some cheap/basic moving heads and have had no problems. However I am looking to upgrade the heads to get away from that jerky motion associated with slow panning or slow tilting that happens on cheap heads. I understand that moving heads with 16 bit pan and tilt precision is the remedy for this, however I stumbled across a post that said QLC+ does not support 16 bit movement?

So if I buy new heads will I not benefit from their 16 bit movement precision if I continue to use QLC+?

[kenact]

Are you setting values in Pan Fine or Tilt Fine? I'm using cheap Tomshine 30w moving heads. The Pan and Tilt movement is smooth, unless I add values for Pan Fine and Tilt Fine, then the movement when fading from one scene to another is erratic.

I believe the problem is how the Fine channel definitions are implemented.

[Russ]

Thanks for your reply. I only use the regular pan and tilt channels, and the heads move smoothly for normal movements, but if I want really slow gradual movements then it's not smooth, it's a bit shaky. I guess because an 8 bit head only has a movement iteration of 2.1 degrees for 540 degrees of pan.

I'm new to all this and am trying to learn as I go , but it would make sense from my basic understanding that for 16 bit moving heads the "fine" channels are combined with the corresponding un-fine channels (regular pan + pan fine, and regular tilt + tilt fine) as each channel is only 8 bit therefore to create a 16 bit data stream the channels are added together. With the fine channel quickly cycling between 0 and 255 for every single digit increment made in the corresponding un-fine channel.

But then I heard that 16 bit was not properly supported by QLC+ but maybe that was a old statement and is not longer the case. Either way I'm keen to know if 16 bit moving heads will work properly with QLC+ or not?

[mcallegari]

For 16bit fade with Scenes you need to set target fine value equal to coarse value.
That's the workaround I announced a few months ago.
viewtopic.php?t=15634
Otherwise use EFX which is dedicated to movements and handles 16bit by design.
Fixture editor has nothing to do with this topic.

[janosvitok]

Hello,

after I read Massimo's answer an idea comes to my mind: Since fades between scenes does not support 16 bit properly and EFX does, you may get around by setting specifix EFX that goes from one scene's position to the next one. you may use either Line or Line 2, set it to Single Shot, set duration to desired fade time, and adjust position so that the start and end points.

Jano

[Russ]

Thanks for the replies and the help guys, much appreciated!

[kenact]

For 16bit fade with Scenes you need to set target fine value equal to coarse value.
That's the workaround I announced a few months ago.

I doubt my Tomshine fixtures are 16 bit, but I did just try what you suggested, setting both Pan Fine and Tilt Fine to the same value as Pan and Tilt respectively. Looking at DMX Monitor, both channels are reacting the same as I stated.

If Pan and Pan Fine are set to 10 in scene 1 and scene 2, Pan Fine will drop to 0 when the fade begins, and back to 10 when the fade ends. The value of Pan does not change.

If Pan and Pan Fine are set to 10 in scene 1 and both are set to 20 in scene 2, Pan Fine will repeatedly scroll from 0 to 255 when the fade begins and stop at 20 when the fade ends. The value of Pan moves directly from 10 to 20 during the fade.

[kenact]

Giving it a little more thought and a little more testing.

I think I understand what the logic should be to ensure smooth panning & tilting (8 bit or 16 bit).

If Pan scene 1 = Pan Scene 2
and Pan Fine scene 1 = Pan Fine scene 2
Neither value should change during a fade.

If Pan scene 1 = Pan scene 2
and Pan Fine scene 1 <> Pan Fine scene 2
Pan fine should change directly from one value to the other, as a normal channel would.

Example: Pan scene 1 = 10, Pan scene 2 = 10
Pan Fine scene 1 = 128, Pan Fine scene 2 = 96
Pan does not change value
Pan Fine should scroll from 128 to 96

If Pan scene 1 > Pan scene 2
and Pan Fine scene 1 = Pan Fine scene 2
Pan should move from value 1 to value 2 as a normal channel does.
Pan Fine should scroll UP from its current value (even if it's 0) to its current value, as many times as the difference between Pan scene 1 and Pan scene 2.

Example: Pan scene 1 = 10, Pan scene 2 = 12
Pan Fine scene 1 = 128, Pan Fine scene 2 = 128
Pan Fine should scroll from 128 to 255 before Pan reaches 11
Pan Fine should scroll from 0 to 255 when Pan moves from 11 to 12
Pan Fine should scroll back up to 128 after Pan reaches 12

If Pan scene 1 < Pan scene 2
and Pan Fine scene 1 = Pan Fine scene 2
Pan should move from value 1 to value 2 as a normal channel does.
Pan Fine should scroll DOWN from its current value to its current value, as many times as the difference between Pan scene 1 and Pan scene 2.

Example: Pan scene 1 = 12, Pan scene 2 = 10
Pan Fine scene 1 = 128, Pan Fine scene 2 = 128
Pan Fine should scroll from 128 to 0 before Pan reaches 11
Pan Fine should scroll from 255 to 0 when Pan moves from 11 to 10
Pan Fine should scroll back down to 128 after Pan reaches 10

Having the value of Pan and Pan Fine both change between scenes is more complicated. Pan Fine still has to scroll up or down, based on the amount of change in Pan, but it also has to land on its own new value.

This is not what's happening. Right now, Pan Fine scrolls from 0 - 255 when its own value changes, regardless of how small the change is. It doesn't appear to be coordinated with the value of Pan. The same is true for Tilt Fine. The only time Pan Fine doesn't move is if it is 0 in both scene 1 and 2.

[giacomo]

hello, here a simple example for v5,
it's not a minor issue and you can judge it better in the 3d view:
2 identical cues and during each transition between identical values the position does 2 little steps, beginning and end of the fade, duration is 3 sec.
The dimensions are real: 10x10 m and H.8m.
In 3d zoom out to visualize the full stage, shortcuts are . next cue , prev cue

fade-pantilt-fine.qxw

(4.39 KiB) Downloaded 133 times

[kenact]

hello, here a simple example for v5,
it's not a minor issue and you can judge it better in the 3d view:
2 identical cues and during each transition between identical values the position does 2 little steps, beginning and end of the fade, duration is 3 sec.
The dimensions are real: 10x10 m and H.8m.
In 3d zoom out to visualize the full stage, shortcuts are . next cue , prev cue
fade-pantilt-fine.qxw

Looking at this example in DMX View, I would say Pan Fine and Tilt Fine are not working properly. From scene 1 to scene 2, where the value of Pan and Pan Fine stay the same, DMX View shows the Pan Fine drops to 0 then returns to the assigned value. Since Pan and Pan Fine have the same value in scene 1 and scene 2, neither Pan nor Pan Fine should change during the fade.

I set the fade to be 3 minutes, to see how Pan Fine works when the values change. It's my opinion that is not working properly. When going down to 233, Pan Fine should stop at 233 when Pan is at 233. Instead, Pan Fine continues down to 0 then jumps to 233. Since the fixture has a 540 degree Pan, the fixture should be panning to 495 degrees. Instead, it's panning to 493 degrees, then jumping back to 495 degrees.

[GGGss]

@Ken,
Actually, it is dead simple: value= (MSB (course) * 256 + LSB fine)), compare source and destination values and do the arithmetic.
In your last example:
scene 1
PAN: 12*256+128 = 3200 (or in hex values: 0xC80)
scene 2
PAN: 10*256+128 = 2688 (0xA80)
going from scene 1 to 2 means going from 3200 -> 2688 so you need negative steps. (Intermediate values for your example: (11*256+0) 2816 (0xB00) , 10*256+255) 2815 (0xAFF)

But the QLC+ engine cannot decompose these intermediate steps vs the time it needs to fulfil the task.

[kenact]

@Ken,
Actually, it is dead simple: value= (MSB (course) * 256 + LSB fine)), compare source and destination values and do the arithmetic.
In your last example:
scene 1
PAN: 12*256+128 = 3200 (or in hex values: 0xC80)
scene 2
PAN: 10*256+128 = 2688 (0xA80)
going from scene 1 to 2 means going from 3200 -> 2688 so you need negative steps. (Intermediate values for your example: (11*256+0) 2816 (0xB00) , 10*256+255) 2815 (0xAFF)

But the QLC+ engine cannot decompose these intermediate steps vs the time it needs to fulfil the task.

Pan Fine is perfectly able to scroll up or down in value.

One of the things it isn't doing is taking the value of Pan into account. If the value of Pan increase in a fade, but the value of Pan Fine decreases, Pan Fine will scroll down from 255 to 0 as many times as its value is decreased, while Pan is increasing in value, which has the effect of working against Pan. The converse is also true.

Let's say Pan is set to 10, which is approximately 21 degrees, and Pan Fine is also set to 10, which adds approximately .082 degrees to the position, making it approximately 21.14 degrees. Doing a 3 second fade to Pan 13 / Pan Fine 7. Pan will jump to 11, while Pan Fine jumps to 255, putting the head at approximately 25 degrees, then sliding back toward 23 degrees. When Pan jumps to 12, Pan Fine return to 255, putting the head at approximately 27degrees, before moving back toward 25 degrees. When Pan reaches 13, Pan Fine will once more jump to 255, putting the head at approximately 29 degrees, before it finally settles at 27.42 degrees. All of that will happen within 3 seconds, making for a very choppy movement. It will be even worse if Tilt Fine has a value greater than zero.

Another issue with Pan Fine is scrolling from 0 to 255 when the value of Pan Fine increases but Pan doesn't change. For example, if Pan Fine increases from 1 to 3, Pan Fine will scroll from 0 to 255 twice, then land on 3. If Pan Fine changes from 1 to 4, it will scroll from 0 to 255 three times before landing on 4. If the value goes from 4 to 1, it will scroll down from 255 to 0 three times before landing on 1.

Something it is doing, which it shouldn't, is dropping to zero when Pan Fine is greater than 0 and doesn't change between scene changes.

By the way, I've been using hexadecimal since 1972. I've even used octal.

[GGGss]

Let's say Pan is set to 10, which is approximately 21 degrees, and Pan Fine is also set to 10, which adds approximately .082 degrees to the position, making it approximately 21.14 degrees. Doing a 3 second fade to Pan 13 / Pan Fine 7. Pan will jump to 11, while Pan Fine jumps to 255, putting the head at approximately 25 degrees, then sliding back toward 23 degrees. When Pan jumps to 12, Pan Fine return to 255, putting the head at approximately 27degrees, before moving back toward 25 degrees. When Pan reaches 13, Pan Fine will once more jump to 255, putting the head at approximately 29 degrees, before it finally settles at 27.42 degrees. All of that will happen within 3 seconds, making for a very choppy movement. It will be even worse if Tilt Fine has a value greater than zero.

This observation I already made some years ago and a case was introduced to Massimo. This part of the code should undergo a revision.
The problem at that time was that my cheap movers had a flaw in its firmware only using 7 bits for the fine channel (so after 127 it jumped to the next MSB bit) Impossible to give a clear use-case at that time...
For him to debug, a mover with 16bit resolution should be donated...

[edit] - I'll take a 16-bit mover with me at home ... to build and also a visual underbuilt case to debug the code.

[janosvitok]

I've thought about this a bit (now this belongs more to development section, but let's keep it here for now):

There are several issues with 16-bit channels, that I've identified (meaning that there are probably more):

(1) actual fading (i.e. iterating from one 16-bit number to another, outputting respective bytes to respective channels). Note that there are fixtures that have 16-bit colors, shutter, so it's not limited to pan and tilt. To complicate things further, there are fixtures with 24-bit channels.

(2) HTP. When deciding if a value overrides another value, both coarse and fine values must be considered.

(3) Relative values. When summing relative values, overflow or underflow may happen.


The best solution for all these is to use 16 channels in all places, and do not allow/show individual channels. For example, the fixture in UI would have only 16 bit PAN channel, and it would be decomposed to coarse and fine very late in the chain, just before DMX output. This solution is most straightforward but also requires lot of work. In fact, I'm afraid it requires rewriting most of QLC+ and also user data.

Simpler solution for (1) and (2) is to create FadeMultiChannel and use it instead of FadeChannel whenever 16 bit channels are involved. I.e. return the same instance for both subchannel, and use it even if only one channel is involved in a particular Function. For (3) a new array in Universe for overflow/underflow may do the trick.