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.
This is pretty kludgy but we need the UIConfiguration object (or any color management object) to be the first to connect to
the ColorsChanged signal.
Might be better to make the UIConfiguration object a delegate for the ThemeManager.
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.
