This commit adds some actions for creating and cycling through tracks.
set_octave_and_ensure_note_change() was refactored to allow switching
tracks to implement the same behaviour.
KnobsWidget is getting pretty bad.
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.
This patch allows roll notes to be of different sizes. This necessitates
a new internal representation of time. BPM and time signatures are
mostly implemented but not exposed.
Roll notes are now sample-accurate and the grid is aligned to 60 BPM
4/4. The roll is divided by the time signature raised to some power of
2, giving the musical divisions of (in the case of 4/4) 16, 32, 64 etc.
Before, our timing was derived from the buffer size and we relied on
that to implement delay. Delay has been rewritten to be sample-granular.
It's now exposed as the proper "divisions of a beat".
Something to be wary of is that the last buffer in the loop is also used
for the start of the next loop. In other words, we loop mid-buffer. This
means we write WAVs with a tiny bit of silence due to breaking the loop
after filling half a buffer.
The data structure for the roll is an array of SinglyLinkedLists of
RollNotes. Separating by pitch (via the array layout) makes insertion
much simpler and faster. Using sorted lists (and thus
SinglyLinkedListIterators) to do lookups is very quick as you know the
sample of the next note and can just compare it to the current sample. I
implemented this with HashMaps and the cost of lookups was abysmal. I
also tried a single SinglyLinkedList and the insertion code got even
more complicated than it already is.
This patch adds the following convenience helper:
auto tab_widget = GUI::TabWidget::construct();
auto my_widget = tab_widget->add_tab<GUI::Widget>("My tab", ...);
The above is equivalent to:
auto tab_widget = GUI::TabWidget::construct();
auto my_widget = GUI::Widget::construct(...);
tab_widget->add_widget("My tab", my_widget);
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.
The piano roll data definitely belongs in AudioEngine along with the
note and time data. Now RollWidget only has GUI information, much like
the other widgets.
Note that this commit exacerbates issue #1158 which is caused by
RollWidget::paint_event().
Notice that we are calculating release time according to the level when
the note is turned off rather than the sustain level. Naively using the
sustain level gives very long release times if you turn the note off
during attack, whereas this deterministically gives the same release
time.
I've been wanting to do this for a long time. It's time we start being
consistent about how this stuff works.
The new convention is:
- "LibFoo" is a userspace library that provides the "Foo" namespace.
That's it :^) This was pretty tedious to convert and I didn't even
start on LibGUI yet. But it's coming up next.
Goals:
- Switch to a more typical LibGUI arrangement
- Separate GUI (MainWidget) and audio (AudioEngine)
- Improve on existing features while retaining the same feature set
Improvements:
- Each GUI element is a separate widget
- The wave (WaveWidget) scales with the window
- The piano roll (RollWidget) scales horizontally and scrolls vertically
- The piano (KeysWidget) fits as many notes as possible
- The knobs (KnobsWidget) are now sliders
- All mouse and key events are handled in constant time
- The octave can be changed while playing notes
- The same note can be played with the mouse, keyboard and roll at the
same time, and the volume of the resulting note is scaled accordingly
- Note frequency constants use the maximum precision available in a
double
