Despite comments already in the code, the logic used to remove a
{Tempo,Meter,BarTime} point from the _points list was incorrect. While it is
true that we can use a duple of (type,time) to find a given point,
::remove_point() was not doing that and instead assumed just the time value
could be used.
This meant that if you placed a tempo and meter at the same point in time, then
changed one of them, ::remove_point() could remove the wrong point from the
_points list.
In #10063 this manifests as the wrong grid being drawn after a tempo point
edit.
This commit alters the ::core_remove_xxx() methods to return a pointer to the
actual Point object that was removed from {_tempos,_meters,_bartimes} and then
we pass that to ::remove_point() for lookup and removal by address.
It also "fixes" a couple of instances of ::core_remove_xxx() without any
removal from the _points list (since ::core_remove_tempo() and
::core_remove_meter() do not do this; ::core_remove_bartime() does,
however). It is not immediately obvious what bad behavior would arise from the
existing code in these cases, but it seems clearly incorrect that the _points
list would contain points no longer present in _tempos or _meters.
This was implemented to try to fix paste() but was not needed. It might be
useful in the future, or just as an expression of the logic of this. Note that
the BBT_Offset it returns only has the beats field set, which is ... odd. So
this is likely not quite finished.
the BBT times of the newly inserted points during paste() are meaningless until
we recompute them using ::reset_starting_at(). So don't try to compute some
sort of likely value, just use the value from the cut buffer, and call
reset_starting_at() after every point inserted.
A meter (time signature) is required to do the math correctly for any operation that may
cross or reach the next bar boundary, which round_to_*() and round_up_to_*() may do.
This reverts commit d3a15b11ba.
This arrived at an awkward time as ScopedTempoMapOwner was being rearranged at
the source level. It will be reapplied in a subsequent commit.
Quantizing superclocks to samples in libtemporal negates the whole purpose of superclocks,
and breaks a variety of things, not limited to moving forward to markers and the grid
There can never be fractional audio time, and since superclock_t is used to represent audio time, when we
convert from Beat time, we should never, ever return a superclock value that does not correspond to
an integer number of samples.
This fixes a number of bugs, including any use of ARDOUR::Filter which writes a new (audio) file
to disk that must be an integer number of samples long, but may be derived from and later used
by a region that had an audio-time duration that is slightly longer (less than one sample)
than the audio file
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.
