Idea for 16 bit solution

Request a feature that you would like to see in QLC+.
Explain in details why you would need it and which is your usage case.
Post Reply
omar86
Posts: 10
Joined: Sat Nov 05, 2016 6:09 pm
Real Name:

Hi all! I was wondering how to bypass the problem of 16 bit support on dimmer channel or other channels. What's about to create a specific channel of max value 65536 instead of 255? Isn't that the same that having two 16 bit channels together (for example pan and pan fine, dimmer and dimmer fine)?
janosvitok
Posts: 1266
Joined: Mon Apr 13, 2015 7:05 am
Location: Bratislava, Slovakia
Real Name: Jano Svitok
Contact:

The devil is in the details... :twisted:

Right, one 16 bit channel is equivalent to 2 8 bit channels. The problem is that QLC+ uses everywhere 8bit channels as well as DMX does.
To support 16 bit channels internally, much of QLC+ must be changed. It's a change of one of the QLC+ base principles.

So unless you provide the details, this idea doesn't bring much. Sorry :)
omar86
Posts: 10
Joined: Sat Nov 05, 2016 6:09 pm
Real Name:

I see. Mmm so I believe we won't never see 16 bit if always must be rewritten.
So there is no easy solution..
Baer
Posts: 96
Joined: Fri Jan 15, 2016 8:40 am
Real Name: Matthias

Just out of curiousity:

What about adjusting the GUI Representation, meaning adding a possiblitity to combine 2 channels in View, but let QLC+ internalle handle this as 2 Channels?

Not sure if any QLC+ internals prevent using this approach, but seems to be the one with the leas rewrite of QLC+ core...
MrBinNZ
Posts: 2
Joined: Mon Jul 16, 2018 8:59 am
Real Name: Drew Bateman

Baer wrote: Mon Apr 24, 2017 9:42 am Just out of curiousity:

What about adjusting the GUI Representation, meaning adding a possiblitity to combine 2 channels in View, but let QLC+ internalle handle this as 2 Channels?

Not sure if any QLC+ internals prevent using this approach, but seems to be the one with the leas rewrite of QLC+ core...
I'd also like to hear if this is workable!
lightweaver
Posts: 14
Joined: Thu May 17, 2018 10:04 pm
Real Name: Brent

+1 for me as well to add to the long term. Lots of fixtures utilising 16 bit on attributes besides pan and tilt
TinouFR
Posts: 1
Joined: Fri Aug 24, 2018 11:23 am
Real Name:

+1 for me as well, I would very much like this feature.

And I think Baer workaround is fast, smart and easy to do temporary solution!
janosvitok
Posts: 1266
Joined: Mon Apr 13, 2015 7:05 am
Location: Bratislava, Slovakia
Real Name: Jano Svitok
Contact:

Problem with Baer's solution is this:

The faders are not a problem. You will get the same result using 2 fader setting 2 channels as you would using 1 fader setting 2 channels.
The real problem is with fading 16 channels, and 16 bit EFX in relative mode.

Fading

Currently Coarse and Fine channels are faded in the same time. So when you go from [0,0] to [255,255], you have 255 steps [1,1], [2,2],...[255,255].
Even worse: fade from [0,255] to [255,0]: [1, 254], [2, 253],...

What you want in the first case is [0,1],...,[0,255], [1,0],[1,1],...[1,255]...[255,255]. Can you see the difference?
This fading is deep in the engine.

EFX relative mode

In this case when you add values, they may over/underflow, so after writing to Fine channel, also the Coarse channel may need adjustments.
This is again deep in the engine.
bcrotaz
Posts: 15
Joined: Fri Feb 07, 2020 7:21 am
Real Name: Bryan Crotaz

If this is still a problem, here's my solution:

Use float internally and convert to integer at the extremities:

Change the core to use float between 0 and 1, everywhere - this might even be a search and replace from byte to float.

Master fader is now applied as value*master, so the maths is very easy.

Then when you render it to DMX, floor(value * 255) for an 8 bit channel or floor(value * 65535) for a 16 bit channel.

In the UI, floor(value * slider_length_in_pixels) etc
User avatar
mcallegari
Posts: 4462
Joined: Sun Apr 12, 2015 9:09 am
Location: Italy
Real Name: Massimo Callegari
Contact:

Post Reply