Corrects a slew of titles, buttons, labels, menu items and status bars
for capitalization, ellipses and punctuation.
Rewords a few actions and dialogs to use uniform language and
punctuation.
When calculating bar height, we clamp our values to the maximum
vertical height of the widget minus a margin. When the window was
resized such that the widget got smaller than this margin however,
our maximum height became negative. This caused a crash in clamp().
These are currently being implicitly including by FixedPoint.h by way of
Format.h. The former will soon be removed from the latter, which would
otherwise cause a compile error in these files.
This has been overkill from the start, and it has been bugging me for a
long time. With this change, we're probably a bit slower on most
platforms but save huge amounts of space with all in-memory sample
datastructures.
Now that we have y-axis (gain) logarithmic display, we should also have
x-axis (frequency) logarithmic display; that's how our ears work. This
can be turned off with an option, but it generally looks much nicer.
For DSP reasons I can't explain myself (yet, sorry), short-time Fourier
transform (STFT) is much more accurate and aesthetically pleasing when
the windows that select the samples for STFT overlap. This implements
that behavior by storing the previous samples and performing windowed
FFT over both it as well as the current samples. This gives us 50%
overlap between windows, a common standard that is nice to look at.
The input to the FFT was distorted by the usage of fabs on the samples.
It led to a big DC offset and a distorted spectrum. Simply removing fabs
improves the quality of the spectrum a lot.
The FFT input should be windowed to reduce spectral leakage. This also
improves the visual quality of the spectrum.
Also, no need to do a FFT of the whole buffer if we only mean to render
64 bars. A 8192 point FFT may smooth out fast local changes but at 44100
hz samplerate that's 200 ms worth of sound which significantly reduces
FPS.
A better approach for a fluent visualization is to do small FFTs at the
current playing position inside the current buffer.
There may be a better way to get the current playing position, but for
now it's implemented as an estimation depending on how many frames where
already rendered with the current buffer.
Also I picked y-axis log scale as a default because there's usually a
big difference in energy between low and high frequency bands. log scale
looks nicer.
Visualization widgets should only have to tell how many samples they
need per frame and have a render method which receives all data relevant
to draw the next frame.
Although it's nice to have this as an option, it should be the default
to adjust higher frequencies as they intrinsically have less energy than
lower energies.
Several related improvements to our Fast Fourier Transform
implementation:
- FFT now operates on spans, allowing it to use many more container
types other than Vector. It's intended anyways that FFT transmutes the
input data.
- FFT is now constexpr, moving the implementation to the header and
removing the cpp file. This means that if we have static collections
of samples, we can transform them at compile time.
- sample_data.data() weirdness is now gone.
When the bars visualization receives a new buffer, it checks if it needs
a new buffer, which is only the case after it has repainted. However,
after then setting m_is_using_last, which is the flag for this, it
checks the buffer size of the passed buffer and returns if that is too
small. This means that if the visualizer receives a buffer that is too
small, and because of external circumstances the update doesn't run
after the buffer modification routine, the m_is_using_last variable is
stuck at true, which means that the visualization incorrectly believes
that the passed buffer is old and we need not update. This simply fixes
that by resetting m_is_using_last if the buffer we're passed is too
small, because in that case, we're clearly not using the last buffer
anymore.
Note: This bug is not exposed by the current SoundPlayer behavior. It
will become an issue with future changes, so we should fix it
regardless.
LibDSP can greatly benefit from this nice FFT implementation, so let's
move it into the fitting library :^)
Note that this now requires linking SoundPlayer against LibDSP. That's
not an issue (LibDSP is rather small currently anyways), as we can
probably make great use of it in the future anyways.
freq_bin was converted to double after it was calculated, so there was
a much higher probability it could be 0 instead of some comma number,
which meant that the bars always stayed on top.
The freq_bin in bins_per_group was multiplied only to be divided later,
which could even result in a crash if you set higher buffer size
(like 1000ms) in PlaybackManager, due to rounding errors I presume.
1) The Sound Player visualizer couldn't deal with small sample buffers,
which occur on low sample rates. Now, it simply doesn't update its
buffer, meaning the display is broken on low sample rates. I'm not too
familiar with the visualizer to figure out a proper fix for now, but
this mitigates the issue (and "normal" sample rates still work).
2) Piano wouldn't buffer enough samples for small sample rates, so the
sample count per buffer is now increased to 2^12, introducing minor
amounts of (acceptable) lag.
AK's version should see better inlining behaviors, than the LibM one.
We avoid mixed usage for now though.
Also clean up some stale math includes and improper floatingpoint usage.
SPDX License Identifiers are a more compact / standardized
way of representing file license information.
See: https://spdx.dev/resources/use/#identifiers
This was done with the `ambr` search and replace tool.
ambr --no-parent-ignore --key-from-file --rep-from-file key.txt rep.txt *
