* use c++20 concepts and numbers for lmms_constants.h
* replace lmms::numbers::sqrt2 with std::numbers::sqrt2
* replace lmms::numbers::e with std::numbers::e
Also replace the only use of lmms::numbers::inv_e with a local constexpr instead
* remove lmms::numbers::pi_half and lmms::numbers::pi_sqr
They were only used in one or two places each
* replace lmms::numbers::pi with std::numbers::pi
* add #include <numbers> to every file touched so far
This is probably not needed for some of these files. I'll remove those later
* Remove lmms::numbers
Rest in peace lmms::numbers::tau, my beloved
* Add missing #include <numbers>
* replace stray use of F_EPSILON with approximatelyEqual()
* make many constants inline constexpr
A lot of the remaining constants in lmms_constants.h are specific to
SaProcessor. If they are only used there, shouldn't they be in SaProcessor.h?
* ok then, it's allowed to be signed
* remove #include "lmms_constants.h" for files that don't need it
- And also move F_EPSILON into lmms_math.h
- And also add an overload for fast_rand() to specify a higher and lower bound
- And a bunch of other nonsense
* ok then, it's allowed to be inferred
* ok then, it can accept an integral
* fix typo
* appease msvc
* appease msvc again
* Replace linearInterpolate with std::lerp()
As well as time travel to undo several foolish decisions and squash tiny
commits together
* Fix msvc constexpr warnings
* Fix msvc float to double truncation warning
* Apply two suggestions from code review
Co-authored-by: Dalton Messmer <messmer.dalton@gmail.com>
* Apply suggestions from code review
Co-authored-by: Dalton Messmer <messmer.dalton@gmail.com>
* fix silly mistake
* Remove SlicerT's dependence on lmms_math.h
* Allow more type inference on fastRand() and fastPow10f()
* Apply suggestions from code review
Co-authored-by: Dalton Messmer <messmer.dalton@gmail.com>
* Clean up fastRand() a little bit more
---------
Co-authored-by: Dalton Messmer <messmer.dalton@gmail.com>
Make the graph scalable by adjusting the painting code of the envelope so that it does not assume fixed widths and heights anymore. Remove the setting of a fixed size from the envelope graph and only set a minimum size.
Make three scaling modes available which can be selected via a context menu in the graph:
* "Dynamic": This modes corresponds to the rendering strategy of the previous implementation. Initially 80/182 of the available width is used as the maximum width per segment. This can be interpreted like a "zoomed" version of the absolute mode. If the needed space becomes larger than the full width though then it falls back to relative rendering.
* "Absolute": Each of the five segments is assigned 1/5 of the available width. The envelopes will always fit but might appear small depending of the current settings. This is a good mode to compare envelopes though.
* "Relative": If there is at least one non-zero segment then the whole width is always used to present the envelope.
The default scaling mode is "Dynamic".
## Technical details
The new painting code is more or less divided into two parts. The first part calculates `QPointF` instances for the different points. In the second part these points are then used to draw the lines and markers. This makes the actual rendering code much more straight forward, readable and maintainable.
The interpolation between the line color of an inactive and an active envelope has also been restructured so that it is much more obvious that we are doing an interpolation in the first place. The colors at both ends of the interpolation are explicit now and can therefore be adjusted much easier. The actual color interpolation is done in the helper function `interpolateInRgb` which is provided by the new class `ColorHelper`. This class will later also be needed when the LFO graph is made scalable.
The line is rendered as a polyline instead of single line segments.
The drawing of the markers has been abstracted into a lambda (with some outside captures though) so that it can be easily adjusted if necessary. The markers are rendered as circles instead of rectangles because that looks much nicer especially when the widget is rendered at a larger size.
The width of the lines and marker outlines is determined using the size of the widget so that it scales with the size.
A `lerp` function has been added to `lmms_math.h`.
