Music-time has a significantly reduced resolution.
When evaluating parameter automation using sample-time, different
samples can be mapped back to the same beat-tick. This can result in
endless loops.
The same automation event is found again:
```
start: 112640 next_event.when: b13334 -> dist a5892029@a662323200 in dist.samples: 1002
start: 113642 next_event.when: b13334 -> dist a269@a668214960 dist.samples: 0
```
Note this fix may not be correct, since time-domains are mixed.
"end" is using sample-time. Furthermore The loop is only entered
if there is an event found using timepos_t(start).
Further work will be required (ideally use the same resolution for
all time-domains, or force everything that is evaluated in RT-context
to a single time-domain)
Program-name is not required to indicate "Tracks", "Busses", etc
Those are always by provided by PROGRAM_NAME.
"Other" really indicates external JACK (or Pipewire) applications.
Here "External" is a better label.
"Misc" can potentially be interpreted ambiguously, hence keeping
PROGRAM_NAME is useful.
OS specific versions part of a http query has been Ardour
only. Mixbus never posted any of this information. The section
was #ifdef'ed out. Removing this code for good, simplifies merges.
* Update button when the name of a connected route changes
* Indicate partial internal connections (previously only the
client name ("ardour") was displayed.
* Escape markup in I/O plugin and client names
* Refactor code, use a common base-class for route and
route-less I/O Buttons
This fixes a deadlock, because tempo-map write copy
was not released. A later call to TempoMap::write_copy
will deadlock and in this case also hold the process lock.
This can happen if there is more than one tempo on the
timeline or if the tempo-difference is too large.
Removing the shadow makes toolbar and editor-tool buttons align
when the editor-mixer is hidden. It also improves consistency
with all other tabs that have no shadow on the left.
Increasing the table border width to 1, makes aligns the
editor-mixer button with the main toolbar.
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
```
