This fixes several callsites that were passing samplepos_t to get a TempoMetric,
some of them somewhat significant (e.g. VST plugins that want tempo information).
Bad API design on my part, apologies.
This commit combines libs/ and gtk2_ardour because the new private status
of the ::metric_at() call would be a blocking point for git bisect
This is mostly a simple lexical search+replace but the absence of operator< for
std::weak_ptr<T> leads to some complications, particularly with Evoral::Sequence
and ExportPortChannel.
This resolves an ambiguity between abs(int) and std::abs(T) which
depends on context and compiler version and optimization.
In context of #9057, (gcc-6.3 -O3) math.h `abs(int)` was used. This
truncated the superclock value to 31 bit in ControlList::extend_to.
Previously the current iterator bbt was moved to p->bbt().
From then on, no grid line is reached if the point p is not on
a bar and mod_bar != 0 or the point is not on an expected beat_div.
e.g. when using bbt += mod_bar, and a tempo-change is at 5|2|0.
iterations continues 6|2|0 7|2|0 is_bar() is always false
and no more grid-lines were added.
Rather than trying
bbt = round-up-to-next-grid-mod-div
and then finding the metric for that position, this
approach only does the latter using the already incremented
BBT position.
We cannot call TempoMetric::superclock_at (BBT_Time) if the BBT time is beyond
the range of the current TempoMetric. We must discover that *before* we make
that call, not as part of the test to see if we've exceeded the range.
There were many logical errors in the previous implementation. This one is
simpler to read, and appears to work much better.
It also allows the caller to specify the quarter-note subdivision to use when
generating the grid, rather than choosing only between some bar modulo or
quarter notes.
introducing a new time signature that uses non-quarter notes as the denominator
will move the beat position a given BBT time (since the middle "B" of BBT
refers to "beats" given by the denominator, not quarters).
This is never for inline references to parameters, only for starting parameter
documentation blocks. The "@p" command is for this, although unfortunately
Doxygen doesn't actually do anything with it and it's just an alias for code
text.
MIDI clock start at the next beat (round_up_to_beat), so
here we have to round the current tick, rather than fall
back to a tick that is not yet complete, as 14da117bc8 does.
Reproduced with the Session from #9027
Start loop at bar 40 with MClk generator enabled.
```
#3 in __GI___assert_fail (assertion=0x7fedd86c4fd5 "clk_pos >= pos", file=0x7fedd86c38b7 "../libs/temporal/tempo.cc", line=3336, function=0x7fedd86c4f60 "void Temporal::TempoMap::midi_clock_beat_at_or_after(Temporal::samplepos_t, Temporal::samplepos_t&, uint32_t&) const") at assert.c:101
#4 in Temporal::TempoMap::midi_clock_beat_at_or_after(long, long&, unsigned int&) const (this= 0x560187e92c00, pos=20691033, clk_pos=@0x7fedc02178b8: 20691032, clk_beat=@0x7fedc02178c4: 11472) at ../libs/temporal/tempo.cc:3336
#5 in ARDOUR::MidiClockTicker::tick(long, long, unsigned int, long) (this=0x56018eed6db0, start_sample=20691033, end_sample=20692057, n_samples=1024, pre_roll=0) at ../libs/ardour/ticker.cc:170
#6 in ARDOUR::Session::send_mclk_for_cycle(long, long, unsigned int, long) (this=0x56018a216340, start_sample=20691033, end_sample=20692057, n_samples=1024, pre_roll=0) at ../libs/ardour/session.cc:7495
#7 in ARDOUR::AudioEngine::process_callback(unsigned int) (this=0x5601881a4f20, nframes=1024) at ../libs/ardour/audioengine.cc:563
```
This fixes various rounding issues. Notably superclock to sample
conversion must always round down when playing forward.
`::process (start, end, speed = 1)` uses exclusive end.
Processing begins at `start` and end ends just before `end`.
Next cycle will begin with the current end.
One example where this failed:
- New session at 48kHz
- Change tempo to 130 BPM
- Enable snap to 1/8 note
- Snap playhead to 1|3|0
- Enable Metronome
- Play
`assert (superclock_to_samples ((*i).sclock(), sample_rate()) < end);`
end = 177231 samples == superclock 1042118280
A grid point is found at superclock 1042116920 (that is < 1042118280).
However converting it back to samples rounded it to sample 177231 == end,
while actual location is 1360 super-clock ticks before end.
The metronome click has to be started this cycle, since the same
position will not be found at the beginning of the next cycle, with
start = 177232.
Similarly a samplecnt_t t, converted to music-time and back must not be
later than the given sample.
```
timepos_t tsc (t);
assert (timepos_t::from_ticks (tsc.ticks ()).samples () <= t);
```
IOW. When playing forward, all super-clock time between 1|1|0 and 1|1|1
should round down to 1|1|0. "We have not yet reached the first tick".
This addressee a bug where ardour 6 was able to write negative
duration `length="-1"` `length-beats="-3.3650500597559585e-05"`
Ideally timecnt_t::string_to should check for invalid,
negative, duration. But this also catches a more generic case.
```
exception at str.substr (1)
#3 Temporal::timepos_t::string_to (this=0x7fffffff7bb0, str="") at libs/temporal/timeline.cc:904
#4 Temporal::timecnt_t::string_to (this=0x7fffffff7ba0, str="-2") at libs/temporal/timeline.cc:294
#5 PBD::string_to<Temporal::timecnt_t> (str="-2") at libs/ardour/ardour/types_convert.h:131
```
The default clock-limit is 99:59:59:00, just under 360000 seconds
(see ARDOUR_UI::parameter_changed, clock-display-limit).
AudioClock calculates this limit pos as
`timepos_t (limit_sec * _session->sample_rate())`
This caused an overflow leading to a negative value:
```
timepos_t (359999 * 96000)
samples_to_superclock (359999 * 96000, 96000)
int_div_round (359999 * 96000 * 282240000, 96000)
```
Ideally this will be optimized, here the sample-rate cancels out,
so we could use a c'tor usin seconds.
In other cases we could cache the pre-calculated sc_per_sample:
`superclock_ticks_per_second() / superclock_t (sr)` which is an
integer for all commonly used sample-rates.
audio time nominally uses superclocks as its canonical unit. However
many things at a higher level only understand samples. If we
increment or decrement a superclock value by 1, the vast majority of
the time we will still get the same sample value after
conversion. Thus to correctly alter an audio time by an amount
that will manifest as 1 sample's difference, we have to use
samples_to_superclock(1)
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.
Paul Davis
Robin Gareus
Ben Loftis
John Emmas
Marijn Kruisselbrink
Gon Solo
David Robillard
luz paz