The Track itself caches the Samples after each processing step which
allows it to be queried without the need to process it every time.
This result is queried by the WaveWidget which then caches the result to
prevent unnecessary heap allocations every paint event.
This makes Piano exactly as usable as when I started the large refactor
some years ago, which *sounds* like I'm a terrible person but now it (1)
looks nicer and (2) has a flexible backend that can already deal with
aribtrary kinds of processors on any track.
This class had slightly confusing semantics and the added weirdness
doesn't seem worth it just so we can say "." instead of "->" when
iterating over a vector of NNRPs.
This patch replaces NonnullRefPtrVector<T> with Vector<NNRP<T>>.
On mouse move the pressed button is not present in the event argument
which causes the corresponding code to never fire. Instead it now stores
the original mouse down event and acts according to that on mouse move.
This has mainly performance benefits, so that we only need to call into
all processors once for every audio buffer segment. It requires
adjusting quite some logic in most processors and in Track, as we have
to consider a larger collection of notes and samples at each step.
There's some cautionary TODOs in the currently unused LibDSP tracks
because they don't do things properly yet.
* Don't inherit from Core::Object everywhere, that's overkill. Use
RefCounted instead.
* Change some constructor visibilites to facilitate the above.
* default-implement all virtual destructors if possible.
* Drive-by include hygiene.
This fixes all current code smells, bugs and issues reported by
SonarCloud static analysis. Other issues are almost exclusively false
positives. This makes much code clearer, and some minor benefits in
performance or bug evasion may be gained.
Previously, a collection of notes (Vector or Array) would be created and
promptly deleted for every sample (at least 44 thousand times per
second!). This was measured to be one of the most significant
performance drawbacks as well as the most obvious performance
improvement I could currently find here. Although it will not cause
Piano to lag currently (at least on virtualized systems), I see an
incoming issue once we get the capability to use more processors.
Now, we use a HashMap correlating pitches to notes, and Track reuses the
data structure in order to avoid reallocations. That is the reason for
introducing the fast clear_with_capacity to HashMap.
