The former was incorrectly implemented, and the latter has already been tested more
in real life.
We should likely remove ::remove_time also and use shift() there too, but that
requires testing negative shifts more broadly.
A group of functionality was only used once, in
TempoPoint::quarters_at_superclock . Keep things simple and enable
further refactoring and cleanup by inlining everything and dropping
superbeat, big_numerator and super_note_type_per_second from Tempo.
The use of big_numerator right next to superclock_ticks_per_second
seems error prone. It should perhaps just be refactored to work in
superclock domain all the time.
It seems weird that the ramped case is much simpler than the non-ramped.
This (pretty much) removes the last references to "superbeat", which
I thus doesn't have to understand ;-)
Make sure all code paths that use Temporal will initialize and reset it
properly. Some code paths (in tet runners) doesn't use Sessions, so
Temporal::reset() has to be invoked directly.
Just set the static superclock variable to 0 as initial value.
TempoMap will still be initialized early as a singleton, but we
introduce a new constructor so it is created empty (and thus not really
usable until Temporal::reset() or similar has populated it).
We can thus drop the static initialization of superclock. The default
superclock rate of 282240000 will now only live in Temporal::reset().
With this change there should no longer be any uninitialized use of
superclock_ticks_per_second(), and there should not be any problems for
DEBUG_EARLY_SCTS_USE to catch. (It is however broken in other ways -
that will be fixed next.)
Basically, if the paste position is not zero and not on a bar line, we will a BBT marker there,
using the existing tempo & meter at that position before the paste.
If the end of the paste is not on a bar line, we will place a BBT marker there,
using the tempo & meter that existed before the paste.
TempoMap::paste() now also accepts an optional final argument that if provided is
used to name the BBT markers, if they are created
the API now provides the option to call ::get_grid() with an iterator which may
be re-used on subsequent calls. This avoids unbounded O(N) "walks" from the
marker preceding the start point of the grid to the start point.
This commit also includes "fast-path" code for the common case of a single
tempo and single meter
