mirror of
https://github.com/LMMS/lmms.git
synced 2026-01-23 22:08:02 -05:00
4a089a19dc
* use c++ std::* math functions This updates usages of sin, cos, tan, pow, exp, log, log10, sqrt, fmod, fabs, and fabsf, excluding any usages that look like they might be part of a submodule or 3rd-party code. There's probably some std math functions not listed here that haven't been updated yet. * fix std::sqrt typo lmao one always sneaks by * Apply code review suggestions - std::pow(2, x) -> std::exp2(x) - std::pow(10, x) -> lmms::fastPow10f(x) - std::pow(x, 2) -> x * x, std::pow(x, 3) -> x * x * x, etc. - Resolve TODOs, fix typos, and so forth Co-authored-by: Rossmaxx <74815851+Rossmaxx@users.noreply.github.com> * Fix double -> float truncation, DrumSynth fix I mistakenly introduced a bug in my recent PR regarding template constants, in which a -1 that was supposed to appear outside of an abs() instead was moved inside it, screwing up the generated waveform. I fixed that and also simplified the function by factoring out the phase domain wrapping using the new `ediv()` function from this PR. It should behave how it's supposed to now... assuming all my parentheses are in the right place lol * Annotate magic numbers with TODOs for C++20 * On second thought, why wait? What else is lmms::numbers for? * begone inline Co-authored-by: Rossmaxx <74815851+Rossmaxx@users.noreply.github.com> * begone other inline Co-authored-by: Rossmaxx <74815851+Rossmaxx@users.noreply.github.com> * Re-inline function in lmms_math.h For functions, constexpr implies inline so this just re-adds inline to the one that isn't constexpr yet * Formatting fixes, readability improvements Co-authored-by: Dalton Messmer <messmer.dalton@gmail.com> * Fix previously missed pow() calls, cleanup Co-authored-by: Dalton Messmer <messmer.dalton@gmail.com> * Just delete ediv() entirely lmao No ediv(), no std::fmod(), no std::remainder(), just std::floor(). It should all work for negative phase inputs as well. If I end up needing ediv() in the future, I can add it then. * Simplify DrumSynth triangle waveform This reuses more work and is also a lot more easy to visualize. It's probably a meaningless micro-optimization, but it might be worth changing it back to a switch-case and just calculating ph_tau and saw01 at the beginning of the function in all code paths, even if it goes unused for the first two cases. Guess I'll see if anybody has strong opinions about it. * Move multiplication inside abs() * Clean up a few more pow(x, 2) -> x * x * Remove numbers::inv_pi, numbers::inv_tau * delete spooky leading 0 Co-authored-by: Dalton Messmer <messmer.dalton@gmail.com> --------- Co-authored-by: Rossmaxx <74815851+Rossmaxx@users.noreply.github.com> Co-authored-by: Dalton Messmer <messmer.dalton@gmail.com>
Spectrum Analyzer plugin
Overview
This plugin consists of three widgets and back-end code to provide them with required data.
The top-level widget is SaControlDialog. It populates configuration widgets (created dynamically) and instantiates spectrum display widgets. Its main back-end class is SaControls, which holds all configuration values.
SaSpectrumView and SaWaterfallView widgets show the result of spectrum analysis. Their main back-end class is SaProcessor, which performs FFT analysis on data received from the Analyzer class, which in turn handles the interface with LMMS.
Threads
The Spectrum Analyzer is involved in three different threads:
- Effect mixer thread: periodically calls
Analyzer::processAudioBuffer()to provide the plugin with more data. This thread is real-time sensitive -- any latency spikes can potentially cause interruptions in the audio stream. For this reason,Analyzer::processAudioBuffer()must finish as fast as possible and must not call any functions that could cause it to be delayed for unpredictable amount of time. A lock-less ring buffer is used to safely feed data to the FFT analysis thread without risking any latency spikes due to a shared mutex being unavailable at the time of writing. - FFT analysis thread: a standalone thread formed by the
SaProcessor::analyze()function. Takes in data from the ring buffer, performs FFT analysis and prepares results for display. This thread is not real-time sensitive but excessive locking is discouraged to maintain good performance. - GUI thread: periodically triggers
paintEvent()of all Qt widgets, includingSaSpectrumViewandSaWaterfallView. While it is not as sensitive to latency spikes as the effect mixer thread, thepaintEvent()s appear to be called sequentially and the execution time of each widget therefore adds to the total time needed to complete one full refresh cycle. This means the maximum frame rate of the Qt GUI will be limited to1 / total_execution_time. Good performance of thepaintEvent()functions should be therefore kept in mind.
Changelog
1.1.2 2019-11-18
- waterfall is no longer cut short when width limit is reached
- various small tweaks based on final review
1.1.1 2019-10-13
- improved interface for accessing SaProcessor private data
- readme file update
- other small improvements based on reviews
1.1.0 2019-08-29
- advanced config: expose hidden constants to user
- advanced config: add support for FFT window overlapping
- waterfall: display at native resolution on high-DPI screens
- waterfall: add cursor and improve label density
- FFT: fix normalization so that 0 dBFS matches full-scale sinewave
- FFT: decouple data acquisition from processing and display
- FFT: separate lock for reallocation (to avoid some needless waiting)
- moved ranges and other constants to a separate file
- debug: better performance measurements
- various performance optimizations
1.0.3 2019-07-25
- rename and tweak amplitude ranges based on feedback
1.0.2 2019-07-12
- variety of small changes based on code review
1.0.1 2019-06-02
- code style changes
- added tool-tips
- use const for unmodified arrays passed to fft_helpers
1.0.0 2019-04-07
- initial release