This is mainly for the benefit of Mixbus, where input_latency
is not propagated upwards from the master bus (no direct
connection).
In Ardour's case _worst_input_latency >= _worst_route_latency
unless a given track with latent plugin is not connected.
Previously looping became out of sync (normal playback was not
affected) when a track had a latent plugin.
Mute and Panner are the only automatable Route owned controls
(that are not managed by a processor). So they need special
casing to be moved when moving a region.
This replaces rule #17, 27, 43 and 59 on
https://manual.ardour.org/appendix/monitor-modes/
"Meter (What you see)" changes to 'Disk (Audio)'
aka "what you hear" in those cases.
This way "what you see" is always "what you hear".
Monitoring inputs is more conveniently done using
the Recorder Page.
The core selection can be (a) stripables (b) automation controls (c) possibly a combination of both
Any given selection op might pass (a) or (b) or (c), so we need to handle the
case where (a) is null.
By default timecode.rate = 30. When 30fps LTC is received,
::detect_ltc_fps() never returned true (FPS changed), and
the TransportMaster never entered "locked" stage.
We now have two basic methods for CoreSelection
* when selecting a stripable, use ::select_stripable_and_maybe_group() with
appropriate arguments to cover the group selection aspects.
* when selecting an automation control that is part of a stripable, call
::select_stripable_with_control()
The old, more simply named methods (set/add/toggle etc.) have all been
made private, and their internal implementations changed somewhat.
This commit includes changes to control surfaces that use CoreSelection directly.
In livetrax, where RF64 is one of two file formats, people frequently end up
with files named .rf64 that are actually .wav due to the libsndfile
header file downgrade. We want to avoid this, and this seems like
a more common case than people generating actual RF64 files that
(now) will be named .wav
see also 2e23ec4422. This fixes a bug where some ports
remain in used (shared_ptr<Port>) by the RCUManager, even
after the port is removed from the port_map.
This can lead to issues when the port is re-registered later.
GCC 14 educates us:
In file included from ../libs/ardour/ardour/io.h:44,
from ../libs/ardour/ardour/route.h:50,
from ../libs/ardour/ardour/session.h:92,
from ../libs/ctrl-interface/midi_surface/midi_surface.cc:30:
../libs/ardour/ardour/port_set.h:92:37: warning: template-id not allowed for constructor in C++20 [-Wtemplate-id-cdtor]
92 | iterator_base<PS,P>(PS& list, DataType type, size_t index)
| ^~
../libs/ardour/ardour/port_set.h:92:37: note: remove the ‘< >’
This works around an issue with some embedded plugin windows not being
properly restored when the window is restored after being minimized. It
also prevents zooming (full-screen) display of dialog windows.
Also recent macOS allows to maximize Windows even if they are not
supposed to be resizable (also causing issues with some plugins).
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.
