Since 5.8-245-g3e43585fa, a response hides the dialog Window
in ArdourDialog::on_response (to prevent dialogs windows staying
around unresponsive while Ardour does background work).
The RF is special, and also the only dialog using explicit
add_action_widget().
A Dialog Window may not be tightly scoped, and may be around
for a while (query settings from the dialog instance). The destructor
may only be called later.
This can be hard to reproduce and I have not been able to work out the steps to
reproduce reliably, but as it is still occuring work around the issue by just
checking the variable is valid before dereferencing it.
Resolves: #7304
Lua serialize() is called recursively and concatenates strings.
(in Lua that results in a new string on the stack, with 2 unused old
strings). Collecting garbage every time becomes expensive, so do it
only once at the end. GUI scripts are not memory limited anyway.
This reverts commit b3722f7063.
In some cases ardour shows context-menu on right-mouse-button
release. In this case selecting a menu-entry should happen
with the left-mouse button (or any button?!)
Using ev->button is only correct if the menu is temporary and only
visible while the button is held, button release then activates the
menu-item.
This needs further work, in some cases allowing any button (0) to work
makes sense and overall consistency needs to be improved.
Different places use different strategies for context-menus which
don't always match the button used in the event-handler.
This is a hotfix (to make TAV context menus work again with left-click)
This fixes an -Woverloaded-virtual ambiguity introduced in b5e613d45
void render (cairo_t*, cairo_rectagle*)
void render (Cairo::RefPtr<Cairo::Context> const&, cairo_rectangle_t*)
ArdourCanvas prefers cairomm and CairoWidget itself uses Cairo::Context,
this improves overall API consistency.
For reasons unknown[1], The vca-counter may not be in sync with
actual number of VCAs present.
[1] possibly some shared-ptr references at the time of session-save, or
old session compatibility.
Note lines on a MIDI-track were able to exceed the time-axis' height
towards the top. If a MIDI track was at the top, the TAV's canvas-group
would increase the overall bounding-box of the track-area and allow
tracks to visually bleed into the time markers group.
* consistent behavior (Route, VCA)
* non-modal
* a single color picker for each RouteUI/VCA at most
* fix bug: VCA picker staying around even when VCA was deleted
This fixes a bug for me:
Measure lines appear & disappear during playback, at certain zoom scales.
I think this is because the unecessary offset was causing beat_density to vary unnecessarily while rolling.
- a tempo marker may now be set to always continue (clamped)
this means that the end tempo of the previous section will
track the start tempo during tempo ops.
it mimics the behaviour in 5.8, with the gui indicating
the curves to be changed.
Work around logic-flow in EngineDialog which should already have
done that, but may no longer heed this special-case if sample-rate
dropdown is refreshed to only devices supported ones.
This should really be split in separate semantics for key and button events.
Fixes a subtle but nasty bug in the EngineDialog where the change of the default focus
widget from a Gtk::Button (acts on press) to an ArdourButton (acts on release) caused
events occuring after a dialog has grabbed focus to trigger button clicks
Stop event propagation. Otherwise, on release the event is passed
up and handled by the TAV which scrolls the editor viewpoint
and the button is no longer under the mouse.
controllable->set_value() from GUI context will eventually queue
a session-rt command. By the time the realtime command runs, the
controllable needs to be in "touch" mode.
The AutomationController "toggle" UI worked around this by directly using
the underlying API (ignoring slaved-controls and ignoring groups).
The RouteUI's GUI wasn't able to write mute-automation at all.
This commit is a compromise: press + hold (touch) + release button.
(it may need further special-casing for _desc.toggled in
AutomationControl::actually_set_value(), also undoing automation-writes
is currently not working correctly)
- a jump in tempo by more than 1 ntpm results in a red
tempo mark pointer.
- ignore UIConfiguration::get_allow_non_quarter_pulse()
when displaying note type in the marker text (only display
note type if we are non-quarter).
- holding down shift before initiating a tempo mark drag
alters the end tempo of the previous one as before, but
this is now a separate drag.
- restore vertical dragging of the tempo mark to alter start/
end tempo. shift during the makrker drag alters start tempo.
xontrol + shift during the drag alters end tempo.
- this implements in the intention behind the previous commit.
a tempo mark is constant until its end has been changed by a
shift-drag on the next marker.
most changes are due to a new design where tempo discontinuities at the
beginning of a ramped section may be set.
this allows easier mapping of live performance, especially in
the common case of a ramped ritard before the beginning of a new section.
feature summary:
holding constraint modifier (shift) while dragging the BBT ruler area
drags the tempo lines by changing the start tempo (as before)
holding copy modifier (control) while dragging the BBT ruler area
drags the tempo lines by changing the end tempo (ahem. not quite there)
dragging a tempo mark while holding constraint (shift) will change the
previous end tempo to match the marker position *worth trying*.
holding constraint and copy modifier (control + shift) while dragging
the BBT ruler area attempts to'pinch' or twist the surrounding tempi
sp that later ones are not repositioned (currently suffereng from
rounding errors)
Tentative solution. Eventually the gain_adjustment should be moved
into the PixFader or SliderController and a dedicated API
should replace gain_adjustment.signal_value_changed()
