dmaax/ladybird
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
ladybird/Userland/Applications/SoundPlayer/BarsVisualizationWidget.h

42 lines
1.2 KiB
C
Raw Normal View History

SoundPlayer: Add a 'Bars' audio visualization
2021-03-21 08:50:58 -03:00
/*
* Copyright (c) 2021, Cesar Torres <shortanemoia@protonmail.com>
Applications: Use default constructors/destructors https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#cother-other-default-operation-rules "The compiler is more likely to get the default semantics right and you cannot implement these functions better than the compiler."
2022-02-10 16:28:48 -03:00
* Copyright (c) 2022, the SerenityOS developers.
SoundPlayer: Add a 'Bars' audio visualization
2021-03-21 08:50:58 -03:00
*
Everything: Move to SPDX license identifiers in all files. 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 *
2021-04-22 05:24:48 -03:00
* SPDX-License-Identifier: BSD-2-Clause
SoundPlayer: Add a 'Bars' audio visualization
2021-03-21 08:50:58 -03:00
*/
#pragma once
SoundPlayer: Fix inconsistencies and code duplication This is a first pass at refactoring SoundPlayer so that the View widget is decoupled from the player itself. In doing so, this fixed a couple of issues, including possibly inconsistent states (e.g. player could be paused and stopped at the same time). With the change, Player actually controls the show, and calls methods overriden by its subclasses to perform actions, such as update the Seek bar; the hard work of massaging the raw data is done by the Player class, so subclasses don't need to reimplement any of these things. This also removes some copies of playlist management code that happened to be copied+pasted inside callbacks of buttons -- it now lives inside a neatly packaged Playlist class, and the Player only asks for the next song to play. In addition, the menu bar has been slightly rearranged.
2021-09-30 01:55:42 -03:00
#include "VisualizationWidget.h"
SoundPlayer: Rework FFT visualization 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.
2022-01-09 19:21:55 -03:00
#include <AK/Array.h>
SoundPlayer: Add a 'Bars' audio visualization
2021-03-21 08:50:58 -03:00
#include <AK/Complex.h>
SoundPlayer: Auto refresh visualization widgets 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.
2022-01-09 18:46:06 -03:00
#include <AK/FixedArray.h>
SoundPlayer: Add a 'Bars' audio visualization
2021-03-21 08:50:58 -03:00
#include <LibGUI/Frame.h>
SoundPlayer: Fix inconsistencies and code duplication This is a first pass at refactoring SoundPlayer so that the View widget is decoupled from the player itself. In doing so, this fixed a couple of issues, including possibly inconsistent states (e.g. player could be paused and stopped at the same time). With the change, Player actually controls the show, and calls methods overriden by its subclasses to perform actions, such as update the Seek bar; the hard work of massaging the raw data is done by the Player class, so subclasses don't need to reimplement any of these things. This also removes some copies of playlist management code that happened to be copied+pasted inside callbacks of buttons -- it now lives inside a neatly packaged Playlist class, and the Player only asks for the next song to play. In addition, the menu bar has been slightly rearranged.
2021-09-30 01:55:42 -03:00
class BarsVisualizationWidget final : public VisualizationWidget {
SoundPlayer: Add a 'Bars' audio visualization
2021-03-21 08:50:58 -03:00
C_OBJECT(BarsVisualizationWidget)
public:
Applications: Use default constructors/destructors https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#cother-other-default-operation-rules "The compiler is more likely to get the default semantics right and you cannot implement these functions better than the compiler."
2022-02-10 16:28:48 -03:00
~BarsVisualizationWidget() override = default;
SoundPlayer: Add a 'Bars' audio visualization
2021-03-21 08:50:58 -03:00
private:
BarsVisualizationWidget();
SoundPlayer: Add samplerate variable to visualizations also fix conflict
2021-03-25 21:28:56 -03:00
LibAudio+LibDSP: Switch samples to 32-bit float instead of 64-bit float 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.
2022-05-06 17:14:16 -03:00
void render(GUI::PaintEvent&, FixedArray<float> const&) override;
SoundPlayer: Show the context menu right under the cursor The context menu used the mouse position by window, which resulted in a pop-up menu in the upper left corner of the screen.
2021-07-11 14:06:20 -03:00
void context_menu_event(GUI::ContextMenuEvent& event) override;
SoundPlayer: Add a 'Bars' audio visualization
2021-03-21 08:50:58 -03:00
SoundPlayer: Use overlapping windows for bars visualization 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.
2022-03-03 18:32:45 -03:00
static constexpr size_t fft_size = 512;
SoundPlayer: Rework FFT visualization 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.
2022-01-09 19:21:55 -03:00
static constexpr size_t bar_count = 64;
SoundPlayer: Implement logarithmic spectrum display 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.
2022-03-03 20:25:15 -03:00
// Things become weird near the Nyquist limit. Just don't use that FFT data.
static constexpr size_t cutoff = fft_size - 32;
SoundPlayer: Rework FFT visualization 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.
2022-01-09 19:21:55 -03:00
LibAudio+LibDSP: Switch samples to 32-bit float instead of 64-bit float 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.
2022-05-06 17:14:16 -03:00
Array<Complex<float>, fft_size> m_fft_samples {};
Array<float, fft_size> m_fft_window {};
Array<float, fft_size / 2> m_previous_samples {};
SoundPlayer: Rework FFT visualization 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.
2022-01-09 19:21:55 -03:00
Array<int, bar_count> m_gfx_falling_bars {};
SoundPlayer: Add a 'Bars' audio visualization
2021-03-21 08:50:58 -03:00
bool m_is_using_last;
bool m_adjust_frequencies;
SoundPlayer: Implement logarithmic spectrum display 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.
2022-03-03 20:25:15 -03:00
bool m_logarithmic_spectrum;
SoundPlayer: Add a 'Bars' audio visualization
2021-03-21 08:50:58 -03:00
RefPtr<GUI::Menu> m_context_menu;
};
Reference in a new issue Copy permalink