1. do more to ensure that we do not call MidiSurface::begin_using_device()
multiple times without ::stop_using_device() in between. This reduces the risk
of duplicate signal handler connections being made (it might even eliminate it).
2. Notify all control surfaces when MIDI connectivity is established AND
disestablished. This gives them a chance to update their notion of their
current connection state. This can be important with JACK across zombification,
but also likely across backend stop&start.
These changes currntly only impact classes derived from MidiSurface but
something equivalent is required for all control surfaces
On macOS popping up a menu with a position function that leads the menu to be
under the mouse pointer generates the same initial set of enter events as on
linux, but this is then followed by some leave events and then a repeat of the
same set of enter events.
this exposes what appears to be a logic error in gtk_menu_enter_notify().
Nonlinear enter events (i.e. where the menu pops up under the mouse, so the
mouse was never actually moved into the menu's window) should not cause a reset
of priv->seen_item_enter. This value, when true, is used to force the next
received button release event to be handle as an menu activation event. This
should only happen when the mouse has actually been moved by the user into the
menu (as already indicated in existing comments). The value has this effect by,
on the next enter event for a menu item, if already set, forcing
menu->activate_time to zero, which in turn will cause menu activation on button
up/release.
This bug doesn't appear on Linux (or Windows) because the event sequence
associated with a menu popup is different. The lack of another set of enter
events means that menu->activate_time is never reset, and so the behavior is as
expected.
This change makes the setting of priv->seen_item_enter be idempotent with
respect to non-linear enter events, which I believe is the intended behavior.
This fixes an issue on Windows, where UI::run can dispatch
a signal that ends up via cross-thread channel at the surfaces'
BaseUI::request_handler. causing a segfault.
First see 31c6f66d9b and 5cb6e1046b.
It worked previously due to `AutomationControl::get_value`
evaluating automation, which was removed in 5cb6e1046b
in favor of properly using latency compensated evaluation.
However due to 31c6f66d9b, fader and trim automation were
never evaluated on locate, only during playback via
`Amp::setup_gain_automation`.
This fixes a case where gain is incorrect after a locate.
The amp still has the gain from before the locate, and when starting
playback ramps to the new gain.
`set_input/output_channels` API to limit a device to the first
`N` chnanels is somewhat ill conveived and was never really
used or useful. LiveTrax has a bitset of exposed channels,
which makes a lot more sense (e.g. hide ADAT or S/Pdif, or
some specific channels)
The MIDI specification makes it quite clear that when a receiver
receives the MSB of a 14 bit controller value, it should consider
the LSB reset to zero. This has been an error in Ardour for many,
many years, though likely of little consequence
This removes the _io_lock in favor of a RCU.
The reason for this change is to ensure data structure
consistency, notably iterators. Previously adding/removing
ports invalidated iterators, which caused [rare] crashes,
since IO::ports() simply returned a PortSet reference.
(This breaks API)
Previously the group-tab extended all the way down to the
last track. Potentially with a widget height of > 2^15 px.
This caused issues with gtk widgets (notably on Windows)
```
unhandled exception (type std::exception) in signal handler:
what: invalid value (typically too big) for the size of the input (surface, pattern, etc.)
```
This also prepares for Mixer Tab-Group to use the same
separation between visible and total extent.
