Q Light Controller+

Hi all

My name is Igor Sane, Im brazilian, and it´s the first time I use this forum.. so.. I have a little problem: I have a NanoKontrol2 and a DMX-USB FTDI device... this devices work very fine in QLC Windows Version... so... I installed the QLC in my raspberry pi3.. and everything work 99% fine... execpted that the faders I mapped to Crossfader on a CUE List... Using the Nanokontrol the left fader never go to 100%.. in the top of a slider, the max percentual is 99%.. If I move with a mouse, I can get the 100%...

My configuration is: Universe 1 = DMX-USB-FTDI devie (a brazilian generic version of a EntTec Open-USB DMX); universe 2 = Nanokontrol2, open and feedback...
The fixture is just have a Generic Dimmer with 24 chanels... The fader are configured the Absolute Values.. I try with Relative Values, so reach 100%, but is very, very slow the fader movement in the QLC...

The right fader work´s fine.. starts in 0% and goes to 100%... If I change the fader map and inverted the fader, the problema persist just in left fader... so I think apparently the problem isn´t in the hardware... I map the others faders in submasters (3,4,5 etc)... and just go to 99% either...

I already have a raspbian (Noob installation), so I installed the QLC like the PDF Manual Instalattion instructed... And work fine.. just this 1% doesnt...
I try to solve puting a original QLC image in another card... And the problem persists in original image! I access the nanoKontrol configuration in windows Korg software and the maximum value of all faders and knobs is correct in 127... I used this software to make the NanoKontrol2 leds work in QLC...

In the small theather that I´m woking, this 1% in the CUE List makes a lot of difference in each scene...

What can I do to solve this? Anyone already have this kind of problem?

Thanks...

All the best

Igor Sane

See a similar problem with my Motorfader Controll from Midi Box. Faders don't reach 100% (or DMX value 255)

I had no time to investigate where this comes from, therefore i haven't filed an issue report yet (because i was not sure if my faders where read badly or if this is really a qlc+ problem), and its not really a big problem for my shows.
But seems to be somehow related to the fact that Midi has only 128 possible values and DMX (and QLC+ internally) uses 256 values.
Maybe there is a problem in extending Midi Range to DMX Range.

With a midi sniffer of some kind you could figure out if it reaches the 127 value.
Maybe intern there might be a lacking round-instruction since 255 (0-based)/127 (0-based) equals 2 and a fraction and not exactly 2. Ergo 255 / 2 = 127,5 in maths.
Binary dividing should be done with shift-registers so [255] (1111 1111) shift to the right = (0111 1111) [127]. Only problem now is how to interpret [1] (0000 0001) with SR gives [0] (0000 0000) and not [1] (0000 0001).

The code to handle 255 is there: https://github.com/mcallegari/qlcplus/b ... ocol.h#L91
The question is why doesn't it help?

Hi All

First, thanks for the repply..

Janositok, maybe the parameter x isnt equal to 127 or UCHAR_MAX is equal to 128 or more... Need to debug this variables... Sorry... I don´t know how to do this...

Someone could do this?

Thank you!

Igor Sane

This

/** Convert MIDI value to DMX value and make 127 == 255 (because 2*127=254) */
#define MIDI2DMX(x) uchar((x == CHAR_MAX) ? UCHAR_MAX : x << 1)

wont work on every compiler becasue acooring to:
http://www.cplusplus.com/reference/climits/

CHAR_MAX is defined as either SCHAR_MAX (127 or greater) or UCHAR_MAX (255 or greater)

Maybe the line need to look like this:
#define MIDI2DMX(x) uchar((x == SCHAR_MAX) ? UCHAR_MAX : x << 1)

Maybe it was orignially tested with a different compiler, or there was a change in gcc or gcc for raspberry pi and gcc on unic differ somehow in type definitions...

Found out a little bit more about this problem:
Looks like on rasperry pi gcc uses unsigned char per default, wich means:

CHAR_MAX == UCHAR_MAX == 255 or greater

Thats the reason why this won't work on raspberry pi 3.

So i would suggest using either SCHAR_MAX insteat of CHAR_MAX, but because this is also implementation dependent, a own define (eg. MIDI_MAX) would be the best choice.

https://github.com/mcallegari/qlcplus/issues/938 so that we don't forget. Thanks for reporting, BTW.

Jano

I've added code to fix the issue. Can you please test (if you can build from source)?

Jano