Q Light Controller+

Hi,

I've noticed a huge slowdown in qlcplus in some cases, and investigated a little.

When pushing a slider on a usb interface, connected to a vcspeeddial, qlcplus can eat a LOT of cpu power.

The widget really eating all the cpu is vccuelist.
Whenever it receives a Doc::functionChanged() signal concerning either the vccuelist's chaser, or any function in the chaser, VCCueList::updateStepList() is called.
And VCCueList::updateStepList() erases the whole widget tree and recreates it.
It can happen 100 times when pushing a slider from the bottom to the top !
So yeah, really slow.

See the attached workspace.

I've been working on a fix ( squashed here https://github.com/plugz/qlcplus/commit ... 595c8d72d4 ), it involves changing the Function::changed() signal to send both the function id and a mask containing the changes made in the function.

It makes it possible to update the parts of the vccuelist we need to update, and not destroying the whole list at every little speed change in a function.

It's not polished yet, but the speed improvement is here and noticeable !

I just want to know if it is worth continuing working down this path, or if you don't want the Function::changed() signal to change.

Regards.

Edit: Also, attached is a screenshot of the changed vccuelist: a common speed is not displayed at each line (update can then take some time too)

Hello David, thanks for investigating this.
I'm very interested in polishing some Speed Dial-related misbehavour.
Another user found something else in the RPi forum:
https://sourceforge.net/p/qlcplus/discu ... e8ea/#9be5

Don't know if the things are related.

As for your change, the Function::changed signal is used everywhere in QLC+, so changing it would mean to test the whole software back again.
I would prefer to optimize the refresh of the Cue list steps.

I've seen also you changed the Cue List headers. Not sure if the theater guys will appreciate changes there.

I'm gonna check the superslow project and see if I can come up with something smart (and quick).

I just want to release this 4.8.0. Can't hold it anymore

Hi Massimo,

* About the other issue: I have no clue...



* About the Function::change signal:
Adding a parameter to the signal will not affect the connected slots.

From Qt doc: "The signals and slots mechanism is type safe: The signature of a signal must match the signature of the receiving slot. (In fact a slot may have a shorter signature than the signal it receives because it can ignore extra arguments.)" ( http://qt-project.org/doc/qt-4.8/signal ... -and-slots )

So, it is not necessary to change the whole QLC+ code.



* About the cue list headers:
Yeah, not pretty, but even when not redrawing the whole tree, just redrawing a whole column seemed kinda slow. (when updating a common fade speed or common duration).
It is just another idea I explored.


* In order to really see the issue, you will need a controller, because with the mouse, not many events are sent.
I may also be something to explore: not registering too many controller events per tick ?



Regards

Ok, some more thoughts about this.

- since chasers are the function with most data in it and widely used, I would add some specific signals to it like: durationChanged, fadeInChanged, fadeOutChanged. So CueListWidget can connect to them instead of just Function::changed. In this way we'd already reduce the processing by 3

- CueListWidget should implement some updateItem function, similar to what the ChaserEditor does

- I believe that most of the users are not interested in Speed Dials milliseconds precision while performing live. Basically they need a precise Tap and a precision around half of a second or so. Sending a million of signals because the time changed from 0.45 to 0.46 doesn't make much sense to me. In this case a proper signal filter would reduce the needed update

- Moreover, if you give the focus to the seconds field, the Speed dial will increase by seconds (and not ms). I would set it by default.

So, I would say checkmate in 4 moves
Anyway, just random thoughts. I need to think a little bit more about it.

> since chasers are the function with most data in it and widely used, I would add some specific signals to it like: durationChanged, fadeInChanged, fadeOutChanged. So CueListWidget can connect to them instead of just Function::changed. In this way we'd already reduce the processing by 3

Yes

> CueListWidget should implement some updateItem function, similar to what the ChaserEditor does

Can't disagree )

> I believe that most of the users are not interested in Speed Dials milliseconds precision while performing live. Basically they need a precise Tap and a precision around half of a second or so.

Can't agree about the precision :
a half-second precision is really NOT precise at all.
Think about a very very simple chaser that puts a light ON and OFF every beat, on a 150 bpm track.
Every second, it will be totally out of sync !

> Moreover, if you give the focus to the seconds field, the Speed dial will increase by seconds (and not ms). I would set it by default.

Because of above, I would not. Besides, signals would still be sent at each input. I don't think precision is the issue here...

> Sending a million of signals because the time changed from 0.45 to 0.46 doesn't make much sense to me. In this case a proper signal filter would reduce the needed update

Yes, and thus the problem is not the precision, but when to send a signal.
Maybe only one signal should be sent for a bunch of changes.
Maybe near the end / beginning of a tick ?


As said before, if you play with your mouse on a speed dial, the slow down is not really bad.
But with a controller (a korg nanokontrol2 in my case), when I push a fader from the bottom to the top, I get 50-100 signals in less than 1/10th of a second.
That is quite a lot.



Cheers

OR we can adopt a QTimer one shot strategy like the one to display the joystick in the input/output page. Let's say with a 200ms timeout, restarted every time a new signal arrives. After 200ms passed, update the Cue List.

Simple and easy as that.

Yes, pretty good solution

https://github.com/mcallegari/qlcplus/pull/354

I've tried it and am very satisfied

Nice, so it seems the Speed Dial topics shown some love at last
David, when you have the chance to try my latest changes on the Tap button can you please tell me what you think ?
Since I don't personally use the Speed Dial widget, I'd like to know if I am improving things or not from someone who uses it.

I found an issue : If I tap to set a tempo, the button will blink accordingly. This is OK. But then, if I change the tempo with the wheel, the button will still be blinking in sync with the first tempo, not in sync with the new set time.
I guess it would be OK to disable the blinking when the time has been changed from another input than the tap button.

But I like the new widget look
And forgetting the previous tap after 30 seconds is nice too !

cheers

You're absolutely right.
I'll make the change later tonight.

As for the 30 seconds...I didn't make that change
Where did you see it ?

Oops, I did not test enough, I though you implemented this too. Maybe this should be an options to enable this or not in a speed dial.

https://sourceforge.net/p/qlcplus/discu ... e8ea/#9be5

It's included in the proposed patches.

Here it is
https://github.com/mcallegari/qlcplus/c ... 6a4ef1143f

Nice !

Still one little issue (sorry :p) :

* Set a tempo by tapping
-> OK, It blinks accordingly to this tempo

* Wait 30 seconds
* Set a new tempo by tapping
-> It blinks accordingly to 2 tempos at the same time

* Wait 30 seconds
* Set a new tempo by tapping
-> It blinks accordingly to TOTAL ANARCHY ! (3 tempos at the same time)

Cheers !

Right, it is fixed now.
Thanks

Works great