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.
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.
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.
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".
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
Also remove Meter:: versions of related methods, because they are not necessary. We
only need metrical information for operations like ::round_to_bar()
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
Ben Loftis
Robin Gareus
John Emmas
David Robillard