This fixes copy/paste of MIDI automation (time-unit: beat) from/to
Parameter automation (time-unit: samples).
It also fixes repeatedly pasting with tempo-ramps: pre-multiply length
before converting to samples.
This is a workaround for performance issues with the current implementation
when adding many regions to the selection one at a time.
If the Selection implementation was to change at some point and adding regions
to the selection only takes a small constant amount of time, then this
optimization may no longer be necessary.
Related to: #7274
Ardour translations and GUI string formatting only depends on the C locale.
Modifying the C++ locale may produce erratic results on various systems
(in particular OSX and macOS) and cause incompatibilies with plugins.
GTK events are still handled while un/loading a session (e.g display
"Loading" message or showing the splash triggers an event-loop run).
Global canvas elements (e.g. Rulers) may respond to session-specific
actions.
Since 5.8-245-g3e43585fa, a response hides the dialog Window
in ArdourDialog::on_response (to prevent dialogs windows staying
around unresponsively while Ardour does background work).
This logic does not apply to Dialog Windows which implement
ProgressReporter or support dialog responses other than OK, Close.
The numeric formatting is equivalent. Even though this string is being used in
the UI as a label I think this is another case where we don't want a localized
numeric string, which would only be relevant with a track count >=1000.
The numeric formatting is equivalent. The string is being used in a label so it
could be argued that we want localized numeric formatting in this case, but as
it is only relevant if we have >=1000 meter strip keep it the same for now.
The C++ global locale is currently set to LC_NUMERIC=C by the first instance of
LocaleGuard so this change means numeric formatting is equivalent.
As the string is being used to construct a label, perhaps we do want to
generate localized numeric formatting in this case. Anyway keep it the same for
now.
string_compose uses std::ostream/stringstream which will insert thousands
separators in some locales. This was not a problem when LocaleGuard set the
global C++ locale to "C"
std::ostream/stringstream will use the current locale to determine the numeric
formatting. If the locale uses grouping then thousands separators will be
inserted in the output which produces an invalid color string in
UIConfiguration::reset_gtk_theme() and when converting colors to strings in
UIConfiguration::store_color_theme()
This has not been a problem so far because it appears that LocaleGuard does not
reset the LC_NUMERIC value for the global C++ locale. So if a LocaleGuard is
created at any time before these functions are called(even if it goes out of
scope) the numeric formatting used by std::streams will use the "C" locale
formatting facets.
No longer need a specialization for bool as PBD::to_string/string_to already
has specializations for bool
Remove template specialization for float as string_to/to_string handles string
representations of infinity
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()
Due to LevelMeterVBox : public LevelMeterBase, public Gtk::VBox;
LevelMeterBase::get_type() overloads Gtk::Widget::get_type(),
Glib::Object::get_type(), Atk::Implementor::get_type() etc..
Besides Ardour-style prefers not to use get_...()