"Mostly" because there are still some issues with horizontal overlap between
entries, but I think that's something that needs to be addressed separately.
Like earlier issues, this was caused by using a screen-derived or default
cairo/pango context. I also tinkered with some constants to make things look
sensible to me, and hopefully everywhere since it should always look the same
with the context fix.
We no longer have a distinct "position" property, because the "length" property
defines both extent and position. But we must not call ::recompute_at_start()
when the position has not changed, so here we use Region::last_length() to
simulate the position property.
These were preventing Ardour from compiling on Windows (Clang or MSVC)
Possibly would've been buildable with MinGW but I don't have that available to test.
Tests showed
ControlSurfacesTest: Tascam US-2400
: [ERROR]: Unknown button ID "F7"
: [ERROR]: Unknown button ID "F8"
This is trying to mitigate it blindfolded.
It doesn't seem like Tascam US-2400 has more than 6 buttons, so it seems
like the profile has been incorrect since it was introduced in 937efdb6.
(But as pointed out in e6de7957, it seems like the profile often isn't
installed and button assignment thus isn't used.)
Tests would fail as:
Test name: AutomationListPropertyTest::basicTest
equality assertion failed
- Expected: 4
- Actual : 5
It is slightly more informative when the size assertion is the last
check and it fails as:
- Expected: state
- Actual : time-domain
The performance benefits from checking size first is not relevant.
With this, all tests are passing for me.
While Ardour doesn't use TDD and has low test coverage, it is nice to
maintain that all active tests are passing.
At present, TempoTwist is Primary-drag on the tempo ruler, and TempoCurve is Primary-drag on the meter
ruler. Not sure that this is quite what we want here, but it makes more sense than the prior
design, in which TempoTwist was available from non-tempo-related rulers
This avoids breaking bindings, and since the action name is generally not a part of the GUI,
really doesn't hurt anything in terms of understandability
An attempt to satisfy #8848.
Add a new action, "fork-regions-from-unselected", which unlinks all
selected MIDI regions from any unselected regions, but maintains links
within the selection, and add the new action to the region MIDI context
menu as "Unlink from unselected". Rename the existing "fork-region" action
to "fork-selected-regions", and amend the existing "Unlink from other
copies" menu item to "Unlink all selected regions" to (try to) clarify the
difference.
Attach the <Tertiary>U default key-binding to the new action: I personally
think it's generally slightly more useful (otherwise I wouldn't have
implemented it), though I'm not that fussed.
In the case that there's only one MIDI region selected, or that none of
the selected regions are mutually linked, both actions will have exactly
the same result. Ideally, we'd only show a single menu item in this case,
but that would require (a) implementing a function to check whether the
selection contains any linked regions, and (b) making the region MIDI
context sub-menu dynamically generated, so that it can change based on the
result of that function, neither of which I've tried to do yet.
Original code is of questionable historical provenance, and
was needlessly (it seems) complexity. New code is relatively
simple arithmetic linear interpolation.
