Usually C++ class instance has the same mem address as its first parent.
LuaBridge uses this to for derived classes. A TemopPoint instance has
the same address as its parent Tempo. However due to virtual inheritance
this was not the case due to a lack of virtual d'tor.
Now the following Lua code works correctly
```
tm = Temporal.TempoMap.read()
tp = Temporal.timepos_t (0)
print (tm:tempo_at(tp):note_type())
```
Previously the last line failed calling Tempo::note_type()
on a TempoPoint instance, due to memory offset e.g.
TempoPoint: 0x600000ff90e0 Tempo: 0x600000ff90e8
Found via `codespell -q 3 -S *.po,./.git,./share/patchfiles,./libs,./msvc_extra_headers,./share/web_surfaces,*.patch -L ba,buss,busses,discreet,doubleclick,hsi,ontop,ro,scrollin,seh,siz,sord,sur,te,trough,ue`
Also remove Meter:: versions of related methods, because they are not necessary. We
only need metrical information for operations like ::round_to_bar()
Loop Location start="a1665678660" end="b145920"
Loop-end (at 122BPM) is a2109859636
at 48kHz this is sample 1794098.32
Now play the loop and play sample 1794098 = a2109859248
Range::squish start: a1665678660 end: a2109859636 squish: a2109859248
squish() does nothing, since there are still 388 superclock-ticks
until the end of the loop.
However, DiskReader::get_midi_playback convertes the value back
to samples(), this leads to effective_start == loop_end;
resulting in an endless loop.
Thanks to MikeLupe to provide a session to reproduce this issue.
When the loop-range is defined in BeatTime, the disk-reader encounters
rounding issues due to time-domain mismatches.
With a simple session fixed BPM at 120, 48kHz.
looping 1 bar exactly 2 sec at the start of the session:
```
Range::squish start: b0 end: b7680 squish: a113554560
Range::squish using modulo: b45 = a661500
Range::squish using modulo in TD: a5760
Range::squish using earlier(): a658560
```
The correct answer is a113554560 - 2 * 56448000 [SC/sec] = a658560
Calculating the modulo iteratively is not great, however usually
only one iteration is required.
This expands significantly the maximum number of Beats that can be represented, which is a good
thing in itself. It slightly speeds up some Beats::operator methods, and slightly slows down
::get_beats() and ::get_ticks().
One minor change in an API user was required, and several tweaks to the unit tests due to the
macros being used by cppunit creating possible type confusion.
Units test pass
When TempoMap::copy_points() is called, the new points are intended to belong
to the (nascent) new map. But the copy constructor for the points leaves the
_map member of a Point unchanged, and so the new points reference the old
map (forever!). ::copy_points() must reset each Point to reference the new map.
Refactored the object that has the _map member, so that we could limit access
to its ::set_map() method to TempoMap.
Because a bartime point IS-A tempo point and IS-A meter point, we cannot just delete the tempo
point passed into core_add_tempo() if the new point replaces an existing one. Ditto for meter.
So, leave that logic up to the caller
timecnt_t and timepos_t constructors with the initial argument as an int64_t
are assumed to be using samples. We need to use the explicit factory methods
instead.
This uses boost::multiprecision::int512_t when multiplying and dividing by the numerator
and denominator of a ratio_t. 128 bits would be sufficient but for some reason, the boost
docs show the 512 bit variant being very slightly faster.
This is a better solution than using a double, which although it will prevent overflow
has fairly limited resolution.
Even if we start at time T, if the tempo point before T is ramped, we need to
adjust it's omega value based on the beat time of the following tempo point. If
we don't do this, then using that tempo to compute ::superclock_at() for
subsequent points will be incorrect.
Note: there may be an ordering issue here with Tempo/Meter points. We might
need to pass over all tempo points first, then process meters etc. Something
like that.
changes in tempo can be negative (decelerando/slowing down), and thus so can _omega. We cannot call log() or its
cousins on negative values, so in this scenario use an alternate expression for "t from b" in the tempo.pdf paper
omega can be computed from Beat or superclock duration. This gives rise to
different units for omega, and we must use the correct value in a given
context.
This commit also changes the way that the audio time omega is computed during
TempoMap::reset_starting_at()
Rampable only existed to provide exclusive access to ::set_end() for the
TempoMap. More idiomatic C++ but now that _type has also gone away, so has
::set_ramped() and it really was not worth keeping it around.
Ramped/Constant is really a function of start/end note_types_per_minute. Having
a separate member is really just caching it and leads to errors or risk thereof.
Temporal::most_recent_engine_sample_rate is used in performance-critical code so shouldn't be accessed via a 'get()' function. But (via the TEMPORAL_SAMPLE_RATE #define) it does get accessed outside of libtemporal and therefore needs to get exported.
We were using a given tempo or meter point as part of the metric used when
recomputing its position. In fact, the metric should be only use the
tempo/meter immediately preceding the given point.
It is more useful to get the actual TempoPoint than just the Tempo
that we discover.
Aside: it would be awesome to understand how to use boost::intrusive to get the
next tempo point directly from the tempo hook.
This commit leaves two issues outstanding:
1. unclear/ugly semantics for drag operations that reset the GUI thread's tempo map to the writable copy
2. undo/redo for the tempo map
These will be addressed in future commits
std::upper_bound() was not the correct tool to find the existing point,
it should have been std::lower_bound(). For code consistency, this
change doesn't use either but like ::remove_tempo() and similar methods,
just iterates over the whole list
We do not want a value as large as the previous one, which limits the time
range that can be represented in 62 bits unnecessarily. The new value is
9 times smaller than the previous value, and loses only 384000 as a significant
factor.
This commit also switches to using an (inline) accessor for superclock_ticks_per_second,
making it possible in debug/testing phases to spot early/illegal uses of the value.
Now using a globally-scoped static variable which is updated by the
AudioEngine whenever an SR change occurs. Defaults to 48kHz and can
be used even before there is a backend.
This just uses the old Evoral BeatTest. Some of the tests needed amending
because temporal uses rint() to convert between float and int, not just
a cast.
THe length of a Source(File) is always measured from its start. In this sense,
the length is like a position on the timeline, which is a duration with an
implicit origin, or a Region start, also a duration with an implicit origin (in
that case the start of the Source). There is no good reason for using
a timecnt_t for this value, because the position component of a timecnt_t
(the origin for the duration) is implicit and always zero. So we make
this property into a timepos_t, and include a number of asserts() to check
for common possible coding errors related to the time domain
This is mainly for the benefit of Lua bindings, but also increases
overall API naming consistency with functions and methods
`is_XYZ()` being used elsewhere.
This API change breaks builds!
::snap_to() was intended to round a Beats value to the nearest multiple
of another Beats value. It did not do that, but instead rounded down.
Worse, it used Beats::operator/ which in turn uses int_div_round(),
which is incorrect for a situation where we need integer truncation.
The changes fix the actual arithmetic and add 2 variant functions so that the
API includes round down, round up and round to nearest.
max_samplepos and max_samplecnt and both INT64_MAX which is (a) too large to fit into a signed 62 bit
integer and (b) definitely too large to be represented in a signed 62 bit superclock value.
Move the constructors that use samplepos_t into the .cc file, and treat these two values as special
cases that mean "as large/late/huge/long as possible".
The old code used the instantaneous tempo at T0 to compute where the next
quarter note would be. This is incorrect, since the tempo is
changing (continuously, for now) during the time represented by that quarter
note. Instead, we need to add a quarter note (or technically, whatever the
tempo note type is) to get a new position in beats, then compute the superclock
time at that location (which will use our equations for tempo, including the
use of omega, the ramp factor).
These comments should correct an impression left in the commit message for
6e9e28343bc3695d that there may be some sort of problem with synchronization
of TempoMap changes. The actual problem is that TempoMap edits are done using
RCU, so the modifications are performaned using a copy of the map, but with
map elements taken from the pre-copy version.
The correct algorithm is to traverse the type-specific list of points,
find the point (if any) whose time matches that of the argument (because
we do not allow multiple points of the same type at the same time), and
then use that discovered point from the _points list.
This approach is required because the actual argument may no longer be
in the tempo map (due to a change made by another thread). The lack of
sync, however, needs investigation.
a negative beat position needs to be legal, so the assert was moved and modified. The only check
for a negative value is that the TempoPoint being used is at absolute zero.
This check might turn out to be wrong in the future, but for now we still require a tempo and
meter point at absolute zero
If time domains differ, it is necessary to first convert the argument duration into a duration
at the position of "this", in the correct time domain. Then we recursively call the operator
again, but this time we will use the fast path that just adds two timepos_t values.
pbd/i18n.h MUST NEVER be included from header files and always be
the last include. This is because `_` is declared other headers
notably boost and some apple headers.
leading to issues like
../libs/pbd/gettext.h:58:27: error: expected unqualified-id before ‘const’
58 | # define gettext(Msgid) ((const char *) (Msgid))
It turned out that 'boost::intrusive::list_base_hook<>' won't compile if its parent class is declared using '__declspec(dllexport)' - so rather than exporting each entire class, let's use the alternative approach and export the various class members individually.
list_member_hook<> is very troublesome in MSVC and is known to cause problems in other compilers when used inside a class which has a virtual base class.
When switching backends, the effective sample-rate is zero.
This only affects the butler thread (the only active thread when
stopped). The actual issue here is the butler calling
"non-realtime-stop" without a backend. However fixing 0/0
generally seems appropriate.
```
#0 in int_div_round<long>(long, long) (x=0, y=0) at ../libs/pbd/pbd/integer_division.h:36
#1 in Temporal::samples_to_superclock(int64_t, int) (samples=0, sr=0) at ../libs/temporal/temporal/superclock.h:39
#2 in Temporal::timepos_t::timepos_t(long) (this=0x7f94bc0a5890, s=0) at ../libs/temporal/temporal/timeline.h:55
#3 in ARDOUR::Automatable::non_realtime_locate(long) (this=0x55a12a980cc8, now=0) at ../libs/ardour/automatable.cc:421
#4 in ARDOUR::Route::non_realtime_locate(long) (this=0x55a12a980ae0, pos=0) at ../libs/ardour/route.cc:5462
#5 in ARDOUR::Session::non_realtime_stop(bool, int, bool&) (this=0x55a12e0cd000, abort=false, on_entry=1, finished=@0x7f94bc0a5e0f: true) at ../libs/ardour/session_transport.cc:1487
#6 in ARDOUR::Session::butler_transport_work(bool) (this=0x55a12e0cd000, have_process_lock=false) at ../libs/ardour/session_transport.cc:1153
#7 in ARDOUR::Butler::thread_work() (this=0x55a12f3b7000) at ../libs/ardour/butler.cc:222
#8 in ARDOUR::Butler::_thread_work(void*) (arg=0x55a12f3b7000) at ../libs/ardour/butler.cc:16
```
Whenever a variable gets declared using 'thread_local' MSVC requires that it should not be compiled with DLL linkage (i.e. it mustn't be exportable). So for Temporal::TempoMap we'll need to export the required members individually, rather than exporting the entire class.
Later I'll need to push some extra changes (to support 'tempo_map_p' and 'boost::intrusive::list' etc) but these initial ones (hopefully!) won't cause any issues for the other builds.
