Scalable LFO graph

[michaelgregorius]

Make the rendering of the LFO graph scalable. Change the fixed size to a minimum size. Adjust the rendering code such that it uses the width and height of the widget instead of the background pixmap.

Use "Hz" instead of "ms/LFO"

Use the more common unit "Hz" to display the frequency of the LFO instead of "ms/LFO". The frequency is always displayed with three digits after the decimal separator to prevent "jumps".

Keep info text legible

Draw a slightly transparent black rectangle underneath the text to keep it legible, e.g. for high frequencies with an LFO amount of 1 which results in a very bright and dense graph.

Take "Freq * 100" into account

This PR also fixes a bug where the "Freq * 100" option was not taken into account when computing and displaying the frequency of the LFO.

Screenshots

Implementation details

Only draw only poly line once instead of many line segments. Collect the points in the for-loop to be able to do so. This makes the code a bit more understandable because we now compute exacly one point per iteration in the for-loop.

Use the same interpolation for the line color like in the envelope graph.

Rename some variables to make them consistent with the other code.

Remove the member m_params which is not used anyway. This also allows for the removal of the overridden modelChanged method.

Extract the drawing of the info text into its own private method drawInfoText.

[Veratil]

Looks good! I wonder if it would be possible to cache the polyline so we don't have to compute it every time? Only need to redraw on parameter changes or resize right?

[michaelgregorius]

Looks good! I wonder if it would be possible to cache the polyline so we don't have to compute it every time? Only need to redraw on parameter changes or resize right?

I assume you mean to cache a QPixmap of the drawn polyline? I think this should be something for another PR. The same should be considered for the envelope lines then.

What is the way to catch parameter changes in LMMS by the way? I guess I would have to connect to a signal of the model(s)?

[Veratil]

I assume you mean to cache a QPixmap of the drawn polyline? I think this should be something for another PR. The same should be considered for the envelope lines then.

The pixmap is definitely a better choice than the polyline itself. 😁 Definitely another PR. I know Qt does some caching of its own though, so we'd have to check if it's going though the loop when nothing is updating.

What is the way to catch parameter changes in LMMS by the way? I guess I would have to connect to a signal of the model(s)?

It would be signals, yeah. We might have to add some extras, but it's out of scope.

[michaelgregorius]

I assume you mean to cache a QPixmap of the drawn polyline? I think this should be something for another PR. The same should be considered for the envelope lines then.

The pixmap is definitely a better choice than the polyline itself. 😁 Definitely another PR. I know Qt does some caching of its own though, so we'd have to check if it's going though the loop when nothing is updating.

It only updates then a damaged region is detected, i.e. if you cover part of the widget and then uncover it. There are some GUI elements which are tied to a timer so that they are updated 60 times a second but the graphs are not in that elusive group.

[Veratil]

It only updates then a damaged region is detected, i.e. if you cover part of the widget and then uncover it.

That's what we hope at least. We have a lot of custom stuff which causes repainting, for instance just moving the mouse in the PianoRoll schedules a paintEvent.

[michaelgregorius]

It only updates then a damaged region is detected, i.e. if you cover part of the widget and then uncover it.

That's what we hope at least. We have a lot of custom stuff which causes repainting, for instance just moving the mouse in the PianoRoll schedules a paintEvent.

I guess the reason is because it is implemented as one big thing that paints everything instead of being composed of parent and child widgets which could react more specifically to certain events. I have just checked and PianoRoll.cpp is peppered with update calls.