Page 1 of 1

Idea for 16 bit solution

Posted: Wed Apr 19, 2017 6:32 am
by omar86
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)?

Re: Idea for 16 bit solution

Posted: Thu Apr 20, 2017 9:34 am
by janosvitok
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 :)

Re: Idea for 16 bit solution

Posted: Thu Apr 20, 2017 5:33 pm
by omar86
I see. Mmm so I believe we won't never see 16 bit if always must be rewritten.
So there is no easy solution..

Re: Idea for 16 bit solution

Posted: Mon Apr 24, 2017 9:42 am
by Baer
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...

Re: Idea for 16 bit solution

Posted: Tue Jul 17, 2018 3:08 am
by MrBinNZ
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!

Re: Idea for 16 bit solution

Posted: Wed Jul 18, 2018 11:48 pm
by lightweaver
+1 for me as well to add to the long term. Lots of fixtures utilising 16 bit on attributes besides pan and tilt

Re: Idea for 16 bit solution

Posted: Fri Aug 24, 2018 11:26 am
by TinouFR
+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!

Re: Idea for 16 bit solution

Posted: Fri Aug 24, 2018 11:51 am
by janosvitok
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.

Re: Idea for 16 bit solution

Posted: Sun Mar 06, 2022 3:10 pm
by bcrotaz
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

Re: Idea for 16 bit solution

Posted: Sun Mar 06, 2022 7:53 pm
by mcallegari