I'm not good with a mouse, so I found it hard to edit animation lines.
The mouse position has to be quite precise, with only a small threshold.
Looking at the code, AutomationLine sets the threshold for the PolyLine
to 4.0 . That seems to be a distance, and better for me than what I
experience.
The actual code in PolyLine is however comparing it directly to the
squared distance, making it more sensitive than expected.
Fixed by computing the squared threshold - also including the line
width.
This fixes the following problem:
When automation lines with significant change are zoomed in time, the
slope gets smaller (towards horizontal) as the control points moves
further away from the visible area. That was rendered correctly, but the
corresponding mouse events happened as if the line had a steeper slope.
The problem was caused by the X value being clamped to the visible area,
without scaling the Y value correspondingly. It has apparently been like
that for a decode, since introduced in c4f0063a68.
The problem is fixed by introducing a clamp2 function that scales the Y
value if clamping the X value.
Note: An old comment says that math goes wrong unless clamping below
COORD_MAX. It is not clear to me what math it refers to, and especially
why we don't need similar clamping on the lower bounds.
And while rarely a real problem, I guess it would be more correct and a
slight optimization to skip all lines where both ends are outside the
same bound. In theory, as it is now, the mouse could catch an invisible
line close to the border.
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.
This moves the _amp from send to delivery (which already
applies gain for the master-bus normalization). This generalizes
the use of a gain stage for use in port-inserts.
Previously active Routes were retained until the end of
Session d'tor and not dropped during Session::destroy.
While most resources were explicitly cleaned up via DropReferences,
Processor UIs are kept around until the actual destructor runs.
Likewise some controllable are kept around while the GraphNode (Route)
owning it is not released.
It can happen that with a scaling factor of 1.0, rubberband
produces slightly fewer samples than the original.
Region::set_length (region->length * 1.0) is idempotent and
does not shorten it as appropriate to the longest source
via Region::verify_length(), which leads to various issues.
* Allow to bundle presets
* Do not use /usr/[local] on Windows
(This may need further work, for Windows, since default user
presets are in `file://$HOME/.ladspa/rdf/`)
Much like the edit-tool and grid-types, clock-modes are UI state.
Saving the UI state separately allows them to be used
consistently for new sessions. Previously clock-modes were set
initially (at application start) and when loading sessions.
The clock modes of newly created sessions was different
depending on loading another session prior to creating the
session. This is now no longer the case.
Re-assigning a sigc::connection does not disconnect
any previously connected signals.
WindowProxy::setup may be called multiple times. Notably plugin
windows can change the managed _window (generic/custom), which
requires a call to setup.
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)
Various operations, notably time-stretch and other filters, directly
added the generated whole-file region to the playlist.
The editor has not listed the generated Region in the RegionList.
This is required when adding locked regions to a playlist.
e.g. after a split or partition operation. It is only supposed
to be used from Playlist::add_region_internal() and
Playlist::partition_internal().
This allows to copy a property list and then selectively
replace various properties. e.g.
```
PropertyList plist (region->properties ());
plist.add (Properties::length, len);
plist.remove (Properties::start);
```
See also 8b0ab38675
and 97f0fac7d5
This also fixes the issue referenced in
8c83149c4c
Before, the .cue file could end up with a mix of latin1 and utf-8
encodings. Utf-8 works better for many things, but that doesn't matter
when the .cue file has to be in latin-1.
Play loop, change loop-location, undo.
Undo calls Locations::set_state, takes a writer-lock,
and calls Location::set_state which emits a Changed signal.
This triggers Editor::location_changed, and if loop-location
changed while looping, update_loop_range_view() queries the
loop location, taking a reader-lock.
This leads to a recursive lock, RWLock::ReaderLock after
a RWLock::WriterLock does not cause a deadlock, however
releasing the ReaderLock effectively also unlocks the WriterLock.
This leads to a deadlock next time a writer-lock is acquired.
