For things like copying from pitch bender to a CC.
Also things like fader to pan, but that seems a bit funny. The conversion
probably needs to be a bit smarter here, perhaps taking the normal into
consideration...
I attempted to preserve the "don't draw unless different" by ditching rounding for more
precise display_span, but that didn't work. An alternative solution would be
to draw on adjustment change if there's text, since then we need to redraw
regardless of slider position, but it seemed weird even just with respect to
the slider, so I opted for this, which really definitely redraws when the
adjustment changes, period.
If this proves to be a performance issue we'll have to figure that out.
Hopefully-desired behaviour is that controls created in the GUI are linear, so
clicking in stuff works like other automation, but controls that originated
from recording are set to discrete so Ardour plays back the input exactly,
instead of doing crazy things like linear interpolation of already high-rate
user input, hold pedals, and so on.
Hopefully that remains the desired behaviour, because we're basically screwed
for ever making any control discrete by default, since we only save the mode to
XML at all if it's not the default, which is currently linear.
Shoot for roughly 30 steps for all controls.
Always keep sensible step information in ParameterDescriptor and just convert
for the UI.
This is a little weird, but it's less weird than it was before, and works.
backends - once instantiated - keep a reference to the engine.
when audioengine is destroyed, the backends must be deinstantiated.
This fixes various unit-test cases.
Among other things, this means that automation controls/lists have the actual
min/max/normal/toggled of parameters, and not those inferred from the Parameter
ID, which is not correct for things like plugin parameters.
Pushing things down to the Evoral::ParmeterDescriptor may be useful in the
future to have lists do smarter things based on parameter range, but currently
I have just pushed down the above-mentioned currently used attributes.
Remove old (already #if 0'ed) implementation of Evoral::coverage() and its
comments.
Tidy up the comment enumerating all the possible ways in which two ranges
can overlap, note the Evoral::OverlapType corresponding to each one, and add
comments to the if()s in coverage corresponding to the cases in the list of
overlap types.
Remove some commented-out assert()s that actually do happen, and re-instate
one that really shouldn't.
Fix a small typo (with -> within)
The various conditionals in Evoral::RangeList::subtract() appear to have
been there to work around
(a) coverage() not always returning the correct value, &
(b) the test suite assuming that the ->to point lies outside the range
Now that these are both fixed, the implementation of subtract() becomes
quite a bit clearer. I replaced the if()s with assert()s for now, but these
shouldn't trip if coverage() is working as I expect.
Also (attempt to) clarify the comments in subtract.
Comments in various call sites of Evoral::coverage() marking things I think
are dubious (with XXX). Also straightened up the alignment of some ASCII
art in libs/ardour/diskstream.cc
Rewrite Evoral::coverage() to (hopefully) do what it's supposed to.
Return OverlapNone for invalid ranges: if either of the ranges passed to
Evoral::coverage() have negative length (i.e. start > end), return OverlapNone
- it seems reasonable to say that a negative-length range can't overlap
anything. Also return OverlapNone from the fallthrough case, though this should
never happen.
Some of the tests for Evoral::RangeList::subtract() assume that ranges
don't contain their end (->to) point. This appears inconsistent with how
they are used elsewhere.
Add some ASCII art comments to the tests to try to clarify what they're
really testing for, and amend subtractTest1, subtractTest4, & subtractTest5
to incorporate the assumption that ranges include their end points.
This is not used anywhere in Evoral and is just a wrapper around the PBD
RingBuffer anyway. Towards a (once again?) independently buildable/testable
Evoral and fewer cross-dependencies.
for one, it can mess up the value when switching to
numeric-entry. It is also rather useless and not
Fader-like (faders are not scrollbars).
Besides, "stepvalue" is way to large and causes jumps
(sometimes step-value is even negative, see
"fast lookahead limiter", "release time"
-> some other bug)
fixes crashes:
* If the Editor-Mixer shows a channel with a plugin that
has been edited in the Mixer, double-clicking the plugin
will try to bring up a 2nd instance of the plugin-UI.
* When closing Ardour both the Mixer and the Editor-Mixer try to delete the underlying plugin, resulting in a double free.
This probably isn't correct in several ways, but it works more than it did, so
I figure it's push worthy.
Still not working:
* Saving mute automation list
* Dragged control points are not snapped to model restrictions
(boolean, in this case, but general problem)
* Line goes funny if you record mute automation
(as opposed to drawing it which works)
This was necessary due to a bug/design issue between Glibmm and Glib (see https://bugzilla.gnome.org/show_bug.cgi?id=561885)
but the problem needs to be managed by the *creator* of the IOSource and that has now moved inside CrossThreadChannel.
Add a test function to test Evoral::coverage() with all possible overlap
types. The first test (line 161) that expects OverlapExternal will fail
with the current implementation of coverage().
There's possibly still a discussion to be had about what the overlap type of
ranges with negative lengths should be: there are currently places in the main
Ardour code base where coverage() is called with ranges where start > end.
Fix compile errors in libs/evoral/test/, by explicitly calling
Evoral::MusicalTime::to_double() wherever a double value is required of a
MusicalTime.
Some of the double variables should probably really be made into MusicalTime
ones instead, but I don't want to mess with this too much.
takeFiveTest still fails for me after this, but a failing test is probably
more informative in the long run than a test that won't even compile.
Reverse the parameters of Mackie::Control::stop_touch() to make them
consistent with AutomationControl::stop_touch(), and fix up the call to
AutomationControl::stop_touch() to have the parameters in the correct
order.
Unfortunately, I don't possess any devices that speak the Mackie protocol, so
though the patch seems logical and correct to me, I have no way of testing it.
If anyone has a device with touch faders that speaks Mackie, I'd be glad of any
confirmation that it at least doesn't break anything.
* ifdef unused static functions
* brackets around assignment and comparision
* no return statement in function returning non-void
* boost concept_checks.hpp unused-local-typedefs
