XY Pad - Reversed + set bound issues

[paktani]

Hello everyone.
I'm was a lurker until now because I was playing around with qlc+ learning how to use it.
I'm getting better every time I use it, but I have a problem on the PAN channel that is driving me crazy from a long time and I'll try to explain it as best as I can, but keep in mind that I'm not so good at english. Feel free to ask for clarifications.

I have 4 American DJ Inno Pocket Spot, 11 ch mode, each one have their address and same configuration in both internal fixture menu and fixtures configuration in qlc+.
My usual case is 2 moving head facing the other 2. I've already found the correct "base" position (DMX 128) that let me to use the "inverse" function keeping the same distance from the edges, but my problem lay in the xy pad.

Ok, let's go pratical: I have 1 xy pad with all 4 fixture associated to it

Scenario #1: No range restrictions, Fixture 1-2 straight, Fixture 3-4 with reversed PAN
--> This works as intended: fixtures 3-4 go from 255 to 0 while fixtures 1,2 go from 0 to 255.

Scenario #2: Range restricted to 40-60%, Fixture 1-2 straight, Fixture 3-4 with reversed PAN
--> This gave me the problem: with the range enabled and pointing the center (that should be a DMX 128 for straight and reversed fixtures, and 50% of the full range) I get the situation in the screenshot: Fixture 1-2 are in the correct value but fixtuers 3-4 get a DMX value of 25, that is totally out from the expected value, that is 128.

Scenario #3: Range restricted to 40-60%, Each fixture is straight (no reversed pan channel), "reversed" modifier set in the FIXTURES->CHANNEL FADE CONFIGURATION for Fictures 3-4 PAN+PAN fine channels
-> Here I get the range working as intended, but this modifier brings me more problem in scenes and EFXs

Now, let's go with theory: If I'm not going to miss anything, the XY pad should work like a converter. If I want a middle position I should have 127 from both straight and reversed channels, but I should get the same value also if I set a range like 40-60% because the halfway is always 50%

Someone does have an explanation about this behaviour? I'm missing something or it's a bug?
Thanks in advance.
Luca

[paktani]

I tried to investigate this issue but I am stuck at the environment configuration on windows, so no more Windows xD
I would like to debug step by step what happen in the calc of the dmx positions and check why the reversed fixtures get the DMX value of 25 instead of 128.
I have Windows, but I understand that it isn't the best solution for this purpose and I should stick at Linux.
My problem is that I am totally out of Linux business and I will go to try to debug an application in a unkowns environment
I will install a Ubuntu on a VM tomorrow and give it a try but as I said I am totally new at Linux.
From a fresh install can I setup QT and start debug following the wikis? Do I need some special things to know before?

Thanks.

[paktani]

Hey guys, sorry to bother you again. I'm working on this, but acually I still have problem setting up a system that let me debug step by step this issue.
Actually I'm trying to take a small part of the source code, translating it on VB using Visual Studio 2015 and test the code from there, scraping the instructions that are "useless" for my case (i.e reading the number of universes)

I would like to ask you if you can spend a little time to check if this problem is deep in the code or if someone of you have the same behaviour, because from 2 weeks I'm trying to set-up this debug-thing but the code is complicated: there are a lot of work behind this software and I've been lost several times

As last odd thing, I tried to edit the VCXYPadFixture.cpp (I was investigating the writeDMX() function) but it seems that the new generated binary do not have the content of the sources. I tried also removing completely big portions of code but nothing changed after compile/build :O

I am on a Windows 7 64 bit system, QT 5.5.1, A lot of VS installed ( I was desperate!) but i tried also un a Ubuntu 15.10. No luck with debugging with both, but the issue is present also in the Linux version.

[Tasaei]

Don't have the answer but yes: i've got problems to with the "invert" xy pad

40%-60% is not the same range as 60%-40% and some how inverted 20-60 hast nearly the same range as inverted 40-60. Normal 20-60 is much much more then 40-60 (of course)


Just to show you're not the only one and pushing this post up

[paktani]

ahahah thank you, after all i'm not alone

[paktani]

Good evening. I have some more details.
I'm trying to figure out what's wrong here. After getting qlc work in Qt creator, still I can't debug because breakpoints aren't working xD
I decided to take a break from Qt Creator and come back to test this behaviour: here I am with some screenshot and a table (and also the correct project file because the original was using a custom made fixture definition)

@Devs, can you give me a hint where conversions and range checks are applied? I checked the VCXYPad::writeDMX(), VCXYPadFixture::writeDMX() and the calls before/after but it seems all in order.
Tomorrow I will do other test copying the code and using the same dummy numbers from code.

You will see a zip attached to this post: it contains other screenshots and the other 2 files attached here.

Thank you for the amazing work!

[paktani]

Finally I've found where the problem is, but it's tricky to resolve. Actualy 2 sections are involved:
VCXYPad::writeXYFixtures() and VCXYPadFixture::writeDMX()

For what I understood the code swap correctly the Min/Max edges but doesn't use the correct offset.
Later I undesrtood the part where the head is flipped using the Y axis (and why is done in this way).

Code: Select all

if (invertedAppearance())
	y = qreal(1) - y;

but when using a range like 60%-40% the bug still remains.
But now I have a good starting point. I am using a "workbench" done with vb.net using the code from the source and adapted where needed that should help me a lot without fight with Qt (that still doesn't work as expected xD)

[paktani]

Good afternoon. I think I've sorted out this problem and the best way to do it is to edit the behaviour of reversed axis.
Let's see an example with numbers:
Range1: 0-20% (DMX:0-51)
Range2: 0-100% (DMX:0-255)
Range3: 40-60% (DMX:102-153)


Actually:
The "reverse" function will reverse only the direction of min->max conversion, doing max->min, than means in other words, that Range1 goes opposite (51-0), Range2 go from 255 to 0 and Range3 should go from 153 to 102. Range 3, as any other min > 0 will not work in the correct range and will get DMX from 51 to 0. See all the precious posts for examples, project file and screenshots


The solution:
The problem reside in VCXYPadFixture.cpp --> VCXYPadFixture::writeDMX() line 488 for X axis and line 490 for Y axis.

Code: Select all

    if (m_xReverse == true)
        xmul = m_xMax - xmul;
    if (m_yReverse == true)
        ymul = m_yMax - ymul;

xmul and ymul are first used as range-relative position, 0 = at minimum and 1=at maximun range
While with a minimun range value = 0 everything *seems* to works, it assume as base that m_xmax is the absolute maximum.
Take Range3, and remember that in the code everything is scaled to a 0->1 scale. Imagine the cursor at minimum position (so an original xmul = 0 that will be 0,4 (the minimum. See the whole code for the formula)
We will have xmul= 0,6 - 0,4 = 0,2. This is WRONG because once converted to dmx we will have 51 as value, while out left posiztion in a scale 40-60& should be 60% = 153.

The correction is so easy, but in will slightly change the behaviour. It will change the direction but also the "zone".
In other words: a Range1 example will show in dialog always as ""Reversed: 20%-0%" but the code will calculate the opposite, so a 100-80% and reverting the direction of course.
(20-0% will convert to dmx codes belonging to the 100-80% range).

This is the same block edited. In short, we take the reference with the maximum real range, that is 255 or 1 in the scale used in the code.

Code: Select all

    if (m_xReverse == true)
        xmul = qreal(1) - xmul;
    if (m_yReverse == true)
        ymul = qreal(1) - ymul;

I've compiled the sources on Ubuntu (last version avaiable from ubuntu website) and it works now.

If I need to clarify something just tell me, because I know to have a bad English.
Can I issue a pull request?

[janosvitok]

I don't have time to check the math now (hopefully I'll do it later) but from the first look it looks reasonable.

Yes, please create pull request and put link to this thread in the comment on github (doesn't need to go to commit message).

Bonus points if you can add unit test for this case: go to ui/test and find any applicable subdir there (most probably vcxypad or vcxypadfixture), add new method to the respective test class.
In this method setup the situation you have (one head normal, one reversed, range1/range2/range3), and check that the code produces correct results. Obviously the tests will fail (that is the point).
Create one commit with the tests and then one commit that fixes the behavior. You may split those 3 ranges (e.g. full range, symmetric range 40-60, and asymmetric 0-20) in three test methods.

Thank you!

[paktani]

This will go far beyond my programming knowledge but I will try to play a little bit and do what you asked.

Thank to you for all the efforts in QLC+

[janosvitok]

I've checked the behaviour, and it is indeed wrong.

What I meant with unit tests is:

- after https://github.com/mcallegari/qlcplus/b ... test.h#L64
add new method writeReverseRange() (and maybe also writeRange)

- after this line: https://github.com/mcallegari/qlcplus/b ... t.cpp#L879
- copy the code from write16bitReverse method,
- adjust the setX method parameters,
- adjust QCOMPARE calls to expect proper values.

In this case please ditch the loop in the method, and provide three calls to writeDMX() - x=0.0, 0.5, and 1.0 (y = whatever)
The loop was meant to be thorough test, but in case the formulas are wrong, the test will accept the data anyway since it uses the same formulas.
Hardcoded numbers are safer here.

Do this three times: for ranges 0-100, 0-20, 40-60, eventually also for 80-100.

Run the code using the test.sh script, or unittests.sh in the top directory.

...it's not that hard

Jano

[paktani]

I had to redo from the beginning becaue I've messed up something and I've got tons of compiling errors xD

I'd forked from the master and uploading files in "My" fork. I will submit a pull request, but I'm totally new at github and I know that I'm going to do a mistake xD Please don't kill me xD


Edit: travis-ci has finished to compile both my pull requests (one for test source files and one for the fix .cpp).
While the test source file has failed as expected , the "fix" fails because changing the behaviour of "reversed" functionality produce different result from the write16bitReverse() comparing points. This function uses hardcoded numbers based on the old behaviour and since I haven't touched it we have "fails".
Should I edit also this function to reflect the "fix"?

[plugz]

Should I edit also this function to reflect the "fix"?

Yes

[paktani]

ahaha I told you that was making some mistakes xD
Now should be everything ok. Travis-ci is compiling the last pull request and I hope that now it will work.
Sorry for those lines Massimo, I swear that they where there for accident. I was sure to had them removed yesterday -.-

Anyway, there is a question for you: it is possible to have a compiled version for windows with these sources? The same sources in Linux will compile, but in windows I receive an error regarding QTest (there is a call that doesnt like to msys2 and that stop everything).
I will have the opportinity to heavily test on duty this and check if it is really fixed or not, but I can work only on windows.