Why is the decimal point being removed from the millisecond box when it sends the value to speeddial.cpp? Meaning, if the box says .99 speeddial.cpp gets the value as 99. So if the value in the box is .09, then speeddial.cpp gets the value as 09, which of course QT will strip the 0, which isn't a bug with QT at all. The problem is, if .09 is in the box, the actual value .09 should be received by speeddial.cpp. This is what is messing it up.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Dude, you're flooding my email box by posting something every ten minutes.
Please calm down with code blind shooting and judgements on something you don't understand.
We understand there is something not right on speed dials, so have patience and we'll fix it.
No need for all this noise.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Start with reading this and then check in QT documentation what the various methods do (e.g. setPrefix()).
You'll see that the decimal point is not a part of the number, just a decoration. The spinbox works with integers. We could use QDoubleSpinBox, but it would contain leading 0 before decimal point. With integers, 09 and 9 is the same thing.
The straightest way to implement this IMO is described in my other comment. For more hint see the accepted answer for this question.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Another suggestion from my side, if you have the chance to work on speed dials: I would like to set the minimum value from external input below 1s, but greater than 0s (f.e. ".20". Does it make sense? :)
Thanks for your effort, guys!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As an idea, why don’t we get rid of the prefix and just add '0ms' as a suffix?
We could then in speeddial.cpp get rid of:
line 286
QString msText = m_ms->text();
int msInt = m_ms->value();
if (msInt < 10 && msText.contains("0") == false)
value += (msInt * MS_DIV * 10);
else
value += (msInt * MS_DIV);
and just have:
value += (msInt * MS_DIV);
I do think a minimum value is worth while, what it should be I am not sure but I think 0.02s or 20ms is about right considering the DMX frame rate.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Regarding the minimum: one thing is that indeed 20ms is reasonable minimum, but you have to handle cases when seconds/minutes/hours are >0 the 0 is allowable minimum for ms (to be able to enter e.g. 3.0s).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Jano, this is another situation where 0ms holds are acceptable. So, if hold seconds/minutes/hours are >0 or if fade-in or fade-out ms/seconds/minutes/hours are >0 then 0ms is allowable.
But then a 20ms hold between fades would be virtually imperceptible, so it may not be necessary.
Last edit: dmxWolf 2015-02-17
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It may be be imperceptible, but it could be critical for exact timing in a show sync to audio situation. More flexibility with QLC+ is better than locking everything down for simplicity. This isn't an Apple product.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2015-02-18
Then you must be using fade-ins and/or Fade-outs.
Not necessarily.
It may be be imperceptible, but it could be critical for exact timing in a show sync to audio situation. More flexibility with QLC+ is better than locking everything down for simplicity.
Yes.
This isn't an Apple product.
Hahaha
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Why is the decimal point being removed from the millisecond box when it sends the value to speeddial.cpp? Meaning, if the box says .99 speeddial.cpp gets the value as 99. So if the value in the box is .09, then speeddial.cpp gets the value as 09, which of course QT will strip the 0, which isn't a bug with QT at all. The problem is, if .09 is in the box, the actual value .09 should be received by speeddial.cpp. This is what is messing it up.
Dude, you're flooding my email box by posting something every ten minutes.
Please calm down with code blind shooting and judgements on something you don't understand.
We understand there is something not right on speed dials, so have patience and we'll fix it.
No need for all this noise.
OK, Point taken. But while I may not understand everything about your code, I have found some things that I KNOW are wrong. Hope you find them.
Good luck! :)
Start with reading this and then check in QT documentation what the various methods do (e.g. setPrefix()).
You'll see that the decimal point is not a part of the number, just a decoration. The spinbox works with integers. We could use QDoubleSpinBox, but it would contain leading 0 before decimal point. With integers, 09 and 9 is the same thing.
The straightest way to implement this IMO is described in my other comment. For more hint see the accepted answer for this question.
I have another idea. When ms value < 10 the spinbox prefix should be ".0"
Makes sense ?
Another suggestion from my side, if you have the chance to work on speed dials: I would like to set the minimum value from external input below 1s, but greater than 0s (f.e. ".20". Does it make sense? :)
Thanks for your effort, guys!
As an idea, why don’t we get rid of the prefix and just add '0ms' as a suffix?
We could then in speeddial.cpp get rid of:
line 286
QString msText = m_ms->text();
int msInt = m_ms->value();
if (msInt < 10 && msText.contains("0") == false)
value += (msInt * MS_DIV * 10);
else
value += (msInt * MS_DIV);
and just have:
value += (msInt * MS_DIV);
I do think a minimum value is worth while, what it should be I am not sure but I think 0.02s or 20ms is about right considering the DMX frame rate.
I already stated (maybe in wrong place) what I think it's needed to do: https://sourceforge.net/p/qlcplus/discussion/general/thread/070c33e3/#dccb
Regarding the minimum: one thing is that indeed 20ms is reasonable minimum, but you have to handle cases when seconds/minutes/hours are >0 the 0 is allowable minimum for ms (to be able to enter e.g. 3.0s).
Also, the minimum should only be for Hold duration, as a 0 for fades is often desired and causes no problems.
I will have a look into working something out here.
I will have to brush off my skills a bit ;-)
For my own usage, the current minimum of 0ms is a good minimum value.
Then you must be using fade-ins and/or Fade-outs.
Jano, this is another situation where 0ms holds are acceptable. So, if hold seconds/minutes/hours are >0 or if fade-in or fade-out ms/seconds/minutes/hours are >0 then 0ms is allowable.
But then a 20ms hold between fades would be virtually imperceptible, so it may not be necessary.
Last edit: dmxWolf 2015-02-17
It may be be imperceptible, but it could be critical for exact timing in a show sync to audio situation. More flexibility with QLC+ is better than locking everything down for simplicity. This isn't an Apple product.
Not necessarily.
Yes.
Hahaha