dmaax/ladybird
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
ladybird/Userland/Applications/Piano/SamplerWidget.cpp

72 lines
2.5 KiB
C++
Raw Normal View History

Piano: Add sampler This commit adds basic support for importing, viewing and playing WAV samples at different pitches. Naming issues: - We are using the Sample struct from Music.h, but also the Sample struct from LibAudio (Audio::Sample). This is a little confusing. set_recorded_sample() finds the peak sample and then divides all the samples by that peak to get a guaranteed min/max of -1/1. This is nice because our other waves are also bound between these values and we can just do the same stuff. This is why we're using Audio::Sample, because it uses floats, whereas Music.h's Sample uses i16s. It's a little annoying that we have to use a mixture of floats and doubles though. For playback at lower frequencies, we're calculating in-between samples, rather than just playing samples multiple times. Basically, you get the current sample and add the difference between the current sample and the next sample multiplied by the distance from the current sample. This is like drawing the hypotenuse of a right-angled triangle.
2020-02-08 03:04:05 -03:00
/*
Everywhere: Tweak "2020-2020" => "2020" in copyright headers
2020-12-25 08:15:16 -03:00
* Copyright (c) 2020, William McPherson <willmcpherson2@gmail.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.
Piano: Add sampler This commit adds basic support for importing, viewing and playing WAV samples at different pitches. Naming issues: - We are using the Sample struct from Music.h, but also the Sample struct from LibAudio (Audio::Sample). This is a little confusing. set_recorded_sample() finds the peak sample and then divides all the samples by that peak to get a guaranteed min/max of -1/1. This is nice because our other waves are also bound between these values and we can just do the same stuff. This is why we're using Audio::Sample, because it uses floats, whereas Music.h's Sample uses i16s. It's a little annoying that we have to use a mixture of floats and doubles though. For playback at lower frequencies, we're calculating in-between samples, rather than just playing samples multiple times. Basically, you get the current sample and add the difference between the current sample and the next sample multiplied by the distance from the current sample. This is like drawing the hypotenuse of a right-angled triangle.
2020-02-08 03:04:05 -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
Piano: Add sampler This commit adds basic support for importing, viewing and playing WAV samples at different pitches. Naming issues: - We are using the Sample struct from Music.h, but also the Sample struct from LibAudio (Audio::Sample). This is a little confusing. set_recorded_sample() finds the peak sample and then divides all the samples by that peak to get a guaranteed min/max of -1/1. This is nice because our other waves are also bound between these values and we can just do the same stuff. This is why we're using Audio::Sample, because it uses floats, whereas Music.h's Sample uses i16s. It's a little annoying that we have to use a mixture of floats and doubles though. For playback at lower frequencies, we're calculating in-between samples, rather than just playing samples multiple times. Basically, you get the current sample and add the difference between the current sample and the next sample multiplied by the distance from the current sample. This is like drawing the hypotenuse of a right-angled triangle.
2020-02-08 03:04:05 -03:00
*/
#include "SamplerWidget.h"
Piano: Allow multiple tracks internally This commit adds multi-track functionality without exposing it to the user. All I really did was rename AudioEngine to Track and allow more than one Track in TrackManager. A lot of the changes are just changing widgets to take a TrackManager and use current_track(). The TrackManager creates Tracks and gives them a read-only reference to the global time value. When the TrackManager wants to fill a sample in the buffer (in fill_buffer()), it calls fill_sample() on each Track. The delay code is slightly different - a Track will fill its m_delay_buffer with the sample it just created rather than the most recent sample in the buffer (which used to be the same thing). TrackManager manages the current octave. Other than those few things, this is a pretty basic separation of concerns.
2020-06-15 02:33:53 -03:00
#include "TrackManager.h"
Piano: Add sampler This commit adds basic support for importing, viewing and playing WAV samples at different pitches. Naming issues: - We are using the Sample struct from Music.h, but also the Sample struct from LibAudio (Audio::Sample). This is a little confusing. set_recorded_sample() finds the peak sample and then divides all the samples by that peak to get a guaranteed min/max of -1/1. This is nice because our other waves are also bound between these values and we can just do the same stuff. This is why we're using Audio::Sample, because it uses floats, whereas Music.h's Sample uses i16s. It's a little annoying that we have to use a mixture of floats and doubles though. For playback at lower frequencies, we're calculating in-between samples, rather than just playing samples multiple times. Basically, you get the current sample and add the difference between the current sample and the next sample multiplied by the distance from the current sample. This is like drawing the hypotenuse of a right-angled triangle.
2020-02-08 03:04:05 -03:00
#include <LibGUI/BoxLayout.h>
#include <LibGUI/Button.h>
#include <LibGUI/FilePicker.h>
#include <LibGUI/Label.h>
#include <LibGUI/MessageBox.h>
#include <LibGUI/Painter.h>
Piano: Allow multiple tracks internally This commit adds multi-track functionality without exposing it to the user. All I really did was rename AudioEngine to Track and allow more than one Track in TrackManager. A lot of the changes are just changing widgets to take a TrackManager and use current_track(). The TrackManager creates Tracks and gives them a read-only reference to the global time value. When the TrackManager wants to fill a sample in the buffer (in fill_buffer()), it calls fill_sample() on each Track. The delay code is slightly different - a Track will fill its m_delay_buffer with the sample it just created rather than the most recent sample in the buffer (which used to be the same thing). TrackManager manages the current octave. Other than those few things, this is a pretty basic separation of concerns.
2020-06-15 02:33:53 -03:00
WaveEditor::WaveEditor(TrackManager& track_manager)
: m_track_manager(track_manager)
Piano: Add sampler This commit adds basic support for importing, viewing and playing WAV samples at different pitches. Naming issues: - We are using the Sample struct from Music.h, but also the Sample struct from LibAudio (Audio::Sample). This is a little confusing. set_recorded_sample() finds the peak sample and then divides all the samples by that peak to get a guaranteed min/max of -1/1. This is nice because our other waves are also bound between these values and we can just do the same stuff. This is why we're using Audio::Sample, because it uses floats, whereas Music.h's Sample uses i16s. It's a little annoying that we have to use a mixture of floats and doubles though. For playback at lower frequencies, we're calculating in-between samples, rather than just playing samples multiple times. Basically, you get the current sample and add the difference between the current sample and the next sample multiplied by the distance from the current sample. This is like drawing the hypotenuse of a right-angled triangle.
2020-02-08 03:04:05 -03:00
{
}
LibAudio/Piano: Replace floats with doubles We should default to double-precision so that clients can make the choice to use float or double.
2020-02-10 09:45:10 -03:00
int WaveEditor::sample_to_y(double percentage) const
Piano: Add sampler This commit adds basic support for importing, viewing and playing WAV samples at different pitches. Naming issues: - We are using the Sample struct from Music.h, but also the Sample struct from LibAudio (Audio::Sample). This is a little confusing. set_recorded_sample() finds the peak sample and then divides all the samples by that peak to get a guaranteed min/max of -1/1. This is nice because our other waves are also bound between these values and we can just do the same stuff. This is why we're using Audio::Sample, because it uses floats, whereas Music.h's Sample uses i16s. It's a little annoying that we have to use a mixture of floats and doubles though. For playback at lower frequencies, we're calculating in-between samples, rather than just playing samples multiple times. Basically, you get the current sample and add the difference between the current sample and the next sample multiplied by the distance from the current sample. This is like drawing the hypotenuse of a right-angled triangle.
2020-02-08 03:04:05 -03:00
{
double portion_of_half_height = percentage * ((frame_inner_rect().height() - 1) / 2.0);
double y = (frame_inner_rect().height() / 2.0) + portion_of_half_height;
return y;
}
void WaveEditor::paint_event(GUI::PaintEvent& event)
{
GUI::Frame::paint_event(event);
GUI::Painter painter(*this);
painter.fill_rect(frame_inner_rect(), Color::Black);
Piano+LibDSP: Move Track to LibDSP This is a tangly commit and it fixes all the bugs that a plain move would have caused (i.e. we need to touch other logic which had wrong assumptions).
2022-07-13 07:44:19 -03:00
// FIXME: This widget currently can't display anything.
return;
Piano: Add sampler This commit adds basic support for importing, viewing and playing WAV samples at different pitches. Naming issues: - We are using the Sample struct from Music.h, but also the Sample struct from LibAudio (Audio::Sample). This is a little confusing. set_recorded_sample() finds the peak sample and then divides all the samples by that peak to get a guaranteed min/max of -1/1. This is nice because our other waves are also bound between these values and we can just do the same stuff. This is why we're using Audio::Sample, because it uses floats, whereas Music.h's Sample uses i16s. It's a little annoying that we have to use a mixture of floats and doubles though. For playback at lower frequencies, we're calculating in-between samples, rather than just playing samples multiple times. Basically, you get the current sample and add the difference between the current sample and the next sample multiplied by the distance from the current sample. This is like drawing the hypotenuse of a right-angled triangle.
2020-02-08 03:04:05 -03:00
}
Piano: Allow multiple tracks internally This commit adds multi-track functionality without exposing it to the user. All I really did was rename AudioEngine to Track and allow more than one Track in TrackManager. A lot of the changes are just changing widgets to take a TrackManager and use current_track(). The TrackManager creates Tracks and gives them a read-only reference to the global time value. When the TrackManager wants to fill a sample in the buffer (in fill_buffer()), it calls fill_sample() on each Track. The delay code is slightly different - a Track will fill its m_delay_buffer with the sample it just created rather than the most recent sample in the buffer (which used to be the same thing). TrackManager manages the current octave. Other than those few things, this is a pretty basic separation of concerns.
2020-06-15 02:33:53 -03:00
SamplerWidget::SamplerWidget(TrackManager& track_manager)
: m_track_manager(track_manager)
Piano: Add sampler This commit adds basic support for importing, viewing and playing WAV samples at different pitches. Naming issues: - We are using the Sample struct from Music.h, but also the Sample struct from LibAudio (Audio::Sample). This is a little confusing. set_recorded_sample() finds the peak sample and then divides all the samples by that peak to get a guaranteed min/max of -1/1. This is nice because our other waves are also bound between these values and we can just do the same stuff. This is why we're using Audio::Sample, because it uses floats, whereas Music.h's Sample uses i16s. It's a little annoying that we have to use a mixture of floats and doubles though. For playback at lower frequencies, we're calculating in-between samples, rather than just playing samples multiple times. Basically, you get the current sample and add the difference between the current sample and the next sample multiplied by the distance from the current sample. This is like drawing the hypotenuse of a right-angled triangle.
2020-02-08 03:04:05 -03:00
{
LibGUI: Use set_layout<LayoutType>() in lots of client code
2020-03-04 05:43:54 -03:00
set_layout<GUI::VerticalBoxLayout>();
Userland+LibGUI: Add shorthand versions of the Margins constructor This allows for typing [8] instead of [8, 8, 8, 8] to specify the same margin on all edges, for example. The constructors follow CSS' style of specifying margins. The added constructors are: - Margins(int all): Sets the same margin on all edges. - Margins(int vertical, int horizontal): Sets the first argument to top and bottom margins, and the second argument to left and right margins. - Margins(int top, int vertical, int bottom): Sets the first argument to the top margin, the second argument to the left and right margins, and the third argument to the bottom margin.
2021-08-16 21:11:38 -03:00
layout()->set_margins(10);
Piano: Add sampler This commit adds basic support for importing, viewing and playing WAV samples at different pitches. Naming issues: - We are using the Sample struct from Music.h, but also the Sample struct from LibAudio (Audio::Sample). This is a little confusing. set_recorded_sample() finds the peak sample and then divides all the samples by that peak to get a guaranteed min/max of -1/1. This is nice because our other waves are also bound between these values and we can just do the same stuff. This is why we're using Audio::Sample, because it uses floats, whereas Music.h's Sample uses i16s. It's a little annoying that we have to use a mixture of floats and doubles though. For playback at lower frequencies, we're calculating in-between samples, rather than just playing samples multiple times. Basically, you get the current sample and add the difference between the current sample and the next sample multiplied by the distance from the current sample. This is like drawing the hypotenuse of a right-angled triangle.
2020-02-08 03:04:05 -03:00
layout()->set_spacing(10);
set_fill_with_background_color(true);
Userspace: Use Core::Object::add() when building interfaces
2020-02-23 06:57:42 -03:00
m_open_button_and_recorded_sample_name_container = add<GUI::Widget>();
LibGUI: Use set_layout<LayoutType>() in lots of client code
2020-03-04 05:43:54 -03:00
m_open_button_and_recorded_sample_name_container->set_layout<GUI::HorizontalBoxLayout>();
Piano: Add sampler This commit adds basic support for importing, viewing and playing WAV samples at different pitches. Naming issues: - We are using the Sample struct from Music.h, but also the Sample struct from LibAudio (Audio::Sample). This is a little confusing. set_recorded_sample() finds the peak sample and then divides all the samples by that peak to get a guaranteed min/max of -1/1. This is nice because our other waves are also bound between these values and we can just do the same stuff. This is why we're using Audio::Sample, because it uses floats, whereas Music.h's Sample uses i16s. It's a little annoying that we have to use a mixture of floats and doubles though. For playback at lower frequencies, we're calculating in-between samples, rather than just playing samples multiple times. Basically, you get the current sample and add the difference between the current sample and the next sample multiplied by the distance from the current sample. This is like drawing the hypotenuse of a right-angled triangle.
2020-02-08 03:04:05 -03:00
m_open_button_and_recorded_sample_name_container->layout()->set_spacing(10);
LibGUI: Rewrite layout system in terms of min and max sizes This patch removes size policies and preferred sizes, and replaces them with min-size and max-size for each widget. Box layout now works in 3 passes: 1) Set all items (widgets/spacers) to their min-size 2) Distribute remaining space evenly, respecting max-size 3) Place widgets one after the other, adding spacing in between I've also added convenience helpers for setting a fixed size (which is the same as setting min-size and max-size to the same value.) This significantly reduces the verbosity of widget layout and makes GML a bit more pleasant to write, too. :^)
2020-12-29 21:23:32 -03:00
m_open_button_and_recorded_sample_name_container->set_fixed_height(24);
Piano: Add sampler This commit adds basic support for importing, viewing and playing WAV samples at different pitches. Naming issues: - We are using the Sample struct from Music.h, but also the Sample struct from LibAudio (Audio::Sample). This is a little confusing. set_recorded_sample() finds the peak sample and then divides all the samples by that peak to get a guaranteed min/max of -1/1. This is nice because our other waves are also bound between these values and we can just do the same stuff. This is why we're using Audio::Sample, because it uses floats, whereas Music.h's Sample uses i16s. It's a little annoying that we have to use a mixture of floats and doubles though. For playback at lower frequencies, we're calculating in-between samples, rather than just playing samples multiple times. Basically, you get the current sample and add the difference between the current sample and the next sample multiplied by the distance from the current sample. This is like drawing the hypotenuse of a right-angled triangle.
2020-02-08 03:04:05 -03:00
Userspace: Use Core::Object::add() when building interfaces
2020-02-23 06:57:42 -03:00
m_open_button = m_open_button_and_recorded_sample_name_container->add<GUI::Button>();
LibGUI: Rewrite layout system in terms of min and max sizes This patch removes size policies and preferred sizes, and replaces them with min-size and max-size for each widget. Box layout now works in 3 passes: 1) Set all items (widgets/spacers) to their min-size 2) Distribute remaining space evenly, respecting max-size 3) Place widgets one after the other, adding spacing in between I've also added convenience helpers for setting a fixed size (which is the same as setting min-size and max-size to the same value.) This significantly reduces the verbosity of widget layout and makes GML a bit more pleasant to write, too. :^)
2020-12-29 21:23:32 -03:00
m_open_button->set_fixed_size(24, 24);
LibGUI: Add Widget focus policies Every widget now has a GUI::FocusPolicy that determines how it can receive focus: - NoFocus: The widget is not focusable (default) - TabFocus: The widget can be focused using the tab key. - ClickFocus: The widget can be focused by clicking on it. - StrongFocus: Both of the above. For widgets that have a focus proxy, getting/setting the focus policy will affect the proxy instead.
2020-10-30 06:58:27 -03:00
m_open_button->set_focus_policy(GUI::FocusPolicy::TabFocus);
Everywhere: Add sv suffix to strings relying on StringView(char const*) Each of these strings would previously rely on StringView's char const* constructor overload, which would call __builtin_strlen on the string. Since we now have operator ""sv, we can replace these with much simpler versions. This opens the door to being able to remove StringView(char const*). No functional changes.
2022-07-11 14:32:29 -03:00
m_open_button->set_icon(Gfx::Bitmap::try_load_from_file("/res/icons/16x16/open.png"sv).release_value_but_fixme_should_propagate_errors());
LibGUI: Include keyboard modifier state with button on_click calls This will allow you us to implement special behavior when Ctrl+clicking a button.
2020-05-12 15:30:33 -03:00
m_open_button->on_click = [this](auto) {
LibGUI: Add parent window argument to FilePicker functions Since FilePicker almost always should be modal, add the parent window as mandatory first argument.
2020-07-15 22:52:02 -03:00
Optional<String> open_path = GUI::FilePicker::get_open_filepath(window());
Piano: Add sampler This commit adds basic support for importing, viewing and playing WAV samples at different pitches. Naming issues: - We are using the Sample struct from Music.h, but also the Sample struct from LibAudio (Audio::Sample). This is a little confusing. set_recorded_sample() finds the peak sample and then divides all the samples by that peak to get a guaranteed min/max of -1/1. This is nice because our other waves are also bound between these values and we can just do the same stuff. This is why we're using Audio::Sample, because it uses floats, whereas Music.h's Sample uses i16s. It's a little annoying that we have to use a mixture of floats and doubles though. For playback at lower frequencies, we're calculating in-between samples, rather than just playing samples multiple times. Basically, you get the current sample and add the difference between the current sample and the next sample multiplied by the distance from the current sample. This is like drawing the hypotenuse of a right-angled triangle.
2020-02-08 03:04:05 -03:00
if (!open_path.has_value())
return;
Piano: Move to LibDSP's Classic synthesizer Almost all synthesizer code in Piano is removed in favor of the LibDSP reimplementation. This causes some issues that mainly have to do with the way Piano currently handles talking to LibDSP. Additionally, the sampler is gone for now and will be reintroduced with future work.
2021-09-28 13:01:39 -03:00
// TODO: We don't actually load the sample.
Piano: Add sampler This commit adds basic support for importing, viewing and playing WAV samples at different pitches. Naming issues: - We are using the Sample struct from Music.h, but also the Sample struct from LibAudio (Audio::Sample). This is a little confusing. set_recorded_sample() finds the peak sample and then divides all the samples by that peak to get a guaranteed min/max of -1/1. This is nice because our other waves are also bound between these values and we can just do the same stuff. This is why we're using Audio::Sample, because it uses floats, whereas Music.h's Sample uses i16s. It's a little annoying that we have to use a mixture of floats and doubles though. For playback at lower frequencies, we're calculating in-between samples, rather than just playing samples multiple times. Basically, you get the current sample and add the difference between the current sample and the next sample multiplied by the distance from the current sample. This is like drawing the hypotenuse of a right-angled triangle.
2020-02-08 03:04:05 -03:00
m_recorded_sample_name->set_text(open_path.value());
m_wave_editor->update();
};
Userspace: Use Core::Object::add() when building interfaces
2020-02-23 06:57:42 -03:00
m_recorded_sample_name = m_open_button_and_recorded_sample_name_container->add<GUI::Label>("No sample loaded");
Piano: Add sampler This commit adds basic support for importing, viewing and playing WAV samples at different pitches. Naming issues: - We are using the Sample struct from Music.h, but also the Sample struct from LibAudio (Audio::Sample). This is a little confusing. set_recorded_sample() finds the peak sample and then divides all the samples by that peak to get a guaranteed min/max of -1/1. This is nice because our other waves are also bound between these values and we can just do the same stuff. This is why we're using Audio::Sample, because it uses floats, whereas Music.h's Sample uses i16s. It's a little annoying that we have to use a mixture of floats and doubles though. For playback at lower frequencies, we're calculating in-between samples, rather than just playing samples multiple times. Basically, you get the current sample and add the difference between the current sample and the next sample multiplied by the distance from the current sample. This is like drawing the hypotenuse of a right-angled triangle.
2020-02-08 03:04:05 -03:00
m_recorded_sample_name->set_text_alignment(Gfx::TextAlignment::CenterLeft);
Piano: Allow multiple tracks internally This commit adds multi-track functionality without exposing it to the user. All I really did was rename AudioEngine to Track and allow more than one Track in TrackManager. A lot of the changes are just changing widgets to take a TrackManager and use current_track(). The TrackManager creates Tracks and gives them a read-only reference to the global time value. When the TrackManager wants to fill a sample in the buffer (in fill_buffer()), it calls fill_sample() on each Track. The delay code is slightly different - a Track will fill its m_delay_buffer with the sample it just created rather than the most recent sample in the buffer (which used to be the same thing). TrackManager manages the current octave. Other than those few things, this is a pretty basic separation of concerns.
2020-06-15 02:33:53 -03:00
m_wave_editor = add<WaveEditor>(m_track_manager);
LibGUI: Rewrite layout system in terms of min and max sizes This patch removes size policies and preferred sizes, and replaces them with min-size and max-size for each widget. Box layout now works in 3 passes: 1) Set all items (widgets/spacers) to their min-size 2) Distribute remaining space evenly, respecting max-size 3) Place widgets one after the other, adding spacing in between I've also added convenience helpers for setting a fixed size (which is the same as setting min-size and max-size to the same value.) This significantly reduces the verbosity of widget layout and makes GML a bit more pleasant to write, too. :^)
2020-12-29 21:23:32 -03:00
m_wave_editor->set_fixed_height(100);
Piano: Add sampler This commit adds basic support for importing, viewing and playing WAV samples at different pitches. Naming issues: - We are using the Sample struct from Music.h, but also the Sample struct from LibAudio (Audio::Sample). This is a little confusing. set_recorded_sample() finds the peak sample and then divides all the samples by that peak to get a guaranteed min/max of -1/1. This is nice because our other waves are also bound between these values and we can just do the same stuff. This is why we're using Audio::Sample, because it uses floats, whereas Music.h's Sample uses i16s. It's a little annoying that we have to use a mixture of floats and doubles though. For playback at lower frequencies, we're calculating in-between samples, rather than just playing samples multiple times. Basically, you get the current sample and add the difference between the current sample and the next sample multiplied by the distance from the current sample. This is like drawing the hypotenuse of a right-angled triangle.
2020-02-08 03:04:05 -03:00
}
Reference in a new issue Copy permalink