Some Issues

Post Reply
uchris

Hello, I'm new in light controlling and QLC+ is the first program i use. It's really nice, but I found some issues.

1) I have a problem with the CUE-List cross-fade function.
I use a generic RGB and added three scenes: red, blue an green, each with one fader to 255. I put them together to a chase whith infinite hold and 0.5s fade. Then I added a chase-list on the virtual desk with this chase. I started it an run some steps manually, then I "linked" the cross-faders an made some steps with the crossfaders. When I go back to the "next" button there occure different problems:
- sometimes it works
- sometimes only the first step is ignored
- sometimes it jumps to an other scene than the next one
- sometimes als channels became 0 and further steps dont change anymore.

2) The same setting as 1
When i now go to the chase editor an change the (global) duration time or the hold time and then change the hold time back to infinity the duration time becomes a strange number (seems like fadein - 0.01 s) Seems like an overflow (hold+maxintegernumber). Should be easy to fix.

The third I can't reproduce now. Maybe I'll post it later.
Michael Clements

Hi Everyone,

Uchris has raised a couple of issues which I had been meaning to mention for some time.

1) After a crossfade(s) using the sliders, the first click on the "next" button is ignored. Subsequent clicks seem to work o.k.

Leaving the sliders somewhere in the middle and then using the "next" button results in not knowing which way the sliders should be moved to get to the next scene - but then, why would you want to do this?

2) As well as what is probably an overflow issue, the cue list ignores infinite duration times if these have been set using the common duration button in the chase editor. Infinite durations have to be set per step, which is unecessarily time consuming.

Plus this one:

3) The crossfade sliders (when linked) do not produce a dipless crossfade (unlike the crossfades produced by the "next" and "back" buttons and by solo buttons with attached scenes) which limits their use to fades to and from blackout for drama productions.

What seems to be going on is that the outputs from the 2 crossfade sliders are being summed HTP. The dip can be seen clearly on a channel that is, say, at 200 in 2 subsequent scenes - its value will dip to 100 at the half way point.
uchris

Okay, I found the mistake on many points of the code. There was also another mistake: When edditing duration, then duration = newduration - fadeIn and so hold = newduration -2*fadein

I corrected all this and will test it now. When everything works, I'll post it here.
uchris

Okay, I corrected it an also did something on the edit.
Now you can write any negative number to duration or hold (or the others) to get infinity. Before you got strange big times, depending on the negative number.
I think the new behaviour is the "right one"

I append the file I've edited, so you can add it to the repository.

Please give me feedback!
Massimo Callegari

Chris, wait a second. Posting source code here, forces the developers to do a manual comparison with the online sources, thus introducing human error and misreading.
I'm afraid this is not the right way to share a change.

There are two options that we'd appreciate:
- a pull request on GitHub
- the change as a .patch file generated with the "diff -Naur" command

Thanks
uchris

Hope I did it right:
Massimo Callegari

Yes, you did it right, thanks.
The only thing that doesn't make sense to me is:
#include "functionliveeditdialog.h"

:)
uchris

Sorry, I wanted to add function.h and the auto-complete funktion of qtcreator did the rest ... but here is the correct diff now:

Can you please push it in the Git repository?
Massimo Callegari

Please don't be impatient.
It is quite a delicate change and it needs to be tested and approved.
For example all the (qint32) and (quint32) casts in your patch are useless, as Function::infiniteSpeed() returns a uint value, suitable for setDuration or step.duration and step.hold.

Also, please next time use Github to submit patches.
uchris

I think at least the the qint32 casts are important, because so we check if the time is infinity (any time >= 2^31).
Without this patch the behaviour is very anoying, because there is no possibility to get working times.

I don't know how to use GitHub, but I'll try next time an create an account.
Massimo Callegari

I am testing the patch. It is NOT OK.
There are regressions because you haven't tested all the cases.
As I said, it's a delicate part of the code.

As for casting, I guess you need to understand the difference between signed and unsigned data first.
uchris

The trick with the sign is also used by Heikki Junnila once in the file


original code:
{
if ((int)m_chaser->duration() setDuration(m_chaser->duration());
else
m_speedDials->setDuration(m_chaser->duration() - m_chaser->fadeInSpeed());
m_speedDials->setDurationTitle(globalHold);
m_speedDials->setDurationEnabled(true);
break;
}


He used (int) instead of "qint32", that should be the same on most systems.

But I'll be patient and have a look on what you push on Github. Then I'll probably see what problem you think of.

EDIT:
Of course I see the differenz, but where did I change the chronology?
EDIT:
Sorry I see a Copy-Paste mistake. I See what you mean.
Massimo Callegari

Chris I'm sorry but I think you're missing the basics of programming, and QLC+ is a complex project.
Heikki, since you named him, is far better than any other developer I've ever met (including me) and he knew precisely what he was doing...not tricks...not magic.

For example, do you understand that
step.hold = newValue;
step.duration = fadeIn + step.hold;
is different from
step.duration = fadeIn + step.hold;
step.hold = newValue;
??
This is basic programming, not rocket science.

Unfortunately I cannot spend my time fixing people's patches nor I can take the responsibility to include a patch and then being the one to blame.
uchris

Sorry Massimo, shame on me, I had a look in the patch file and saw a very bad copy-paste mistake. I copied it in the wrong order. I'll do a better patch and then do a pull request on Github.
In the same patch I'll also handle some more cases that probably will never ever happen (but just for the case if).
uchris

Okay, I see you corrected this one big copy-paste mistake. Thank you.
Massimo Callegari

I moved this to the development thread.
I pushed the (hopefully) fixed patch on Github.
Please do so more tests if you can.
Tomorrow I'm going to release version 4.8.2.
Post Reply