the rest from `tools/convert_boost.sh`.
* replace boost::function, boost::bind with std::function and std::bind.
This required some manual fixes, notably std::placeholders,
some static_casts<>, and boost::function::clear -> = {}.
Also move code for adding automation line control points into automation line, rather
than in AutomationTimeAxisView (some work still required to finalize this)
This reverts commit c578695a64.
When hovering over a control point there is still the "Fader"
cursor shown. It is also handy to be able to directly modify
a control-point right after adding it.
A freehand draw operation can be still be initiated above,
below, or left/right of a given control point.
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.
The old code could not snap to the grid, because it had a lot of confusion about pixels vs. time,
and between line-origin-relative time and absolute time
Due to refactoring in d41e66f169 and 83ad0a10b5
Automation > Clear re-displayed the line on mouse-over, even
if there are no events. Then trying to interact with he line
caused segfaults because the actual control points no longer exist.
this adds points to the lines so that they always extend to the edge of
regions (not control points).
more work to come to unify ::redisplay() and ::reset_callback()
The fix here is really just dropping the use of _offset when computing the session position
of a control point. This was just an arithmetical error.
However, session_sample_position() was redundant and just caused more work, so this
method was removed, and only ::session_position() is now used.
In addition, several closely related places now use C++11 (or later) "auto"
syntax for iterating over containers, for cleaner looking code
* control points that were already closer than one_tick_in_pixels
were able to move beyond adjacent points, resulting in out-of-order lines
* prior code was using 'one tick' as the smallest spacing between two
CPs, but that is larger than the default 'guard point' spacing. this
resulted in odd behavior because of the dxt calculation when you moved
a point that was created as a 'guard point'
For now, use the same 64 samples we use for 'guard points'. And change
the 'dxt' calculation logic to more aggressively limit the points from
overlapping.
TODO: we might decide that 'one tick' should be the minimum automation
period throughout ardour. In that case we should change guard-points.
This fixes various offset issues when editing MIDI (CC)
automation as well as RegionGain range and point based editing.
(It does not fix a related issue that region start-trim
offsets region-gain. Historically region-gain _offset is always
zero, regardless of region->start().
