Collecting bindings after ::finish() has already destroyed half the GUI
will result in memory corruption invalid Glib::RefPtr<Gtk::Action>
Gtkmm2ext::ActionMap::get_actions()
Gtkmm2ext::Bindings::get_all_actions()
KeyEditor::Tab::populate()
KeyEditor::refresh()
Editor::set_script_action_name()
LuaInstance::session_going_away()
PBD::Destructible::drop_references()
ARDOUR::Session::destroy()
ARDOUR::Session::~Session()
ARDOUR_UI::finish()
At the point of creation, the automate_button size request is wrong
since it has not the correct style yet. Instead of trying ugly hacks to
fix that, connect to the knob's size_request signal and get the button's
requisition only when needed. If the system font changes to one that has
different extents (even if the point size is the same), the UI will thus
correctly update.
So that the padding and other elements always correctly depend on the
font instead of the default GTK font (which might have a wildly
different size from the fixed size fonts of Ardour's custom theme).
In the normal course of events, an ArdourButton requests just enough
space to display its elements. In particular the size will change when
the text does. Yet, in several cases it is better to avoid layout jittering; until now ArdourButton users manually set a static size on the button at creation time.
Introduce new API to set the text used for measuring the button size
separately from the text that will be displayed. In most cases this
enables the callers to replace
set_size_request_to_display_given_text(button, text, w, h);
where w and h were hard-coded to cater for other button elements, by
button.set_sizing_text(text);
which will make ArdourButton correctly compute the size request in all
cases with its real elements and padding. ArdourButton users can call
button.set_sizing_text("");
to get the size request depend on displayed text (which is the default).
The insensitive state should not get a base color that's the same as the
enabled one, or the difference is not visible enough (only the text
color changes). In fact, since the goal of the entry modifications is to
aid visibility during user input, there is no reason to override the
insensitive colors.
Just inherit the insensitive colors of the global style.
Also fix a comment that was attached to the wrong declaration.
- Holding the constraint modifier at the time of grab gives constrained x.
- Holding the constraint modifier after the grab but before the first motion
constrains to the direction of first movement.
With the same color code as the fader automation button on mixer strips.
This is especially usefull when use_knob is true (e.g. for a-EQ) because
the automation only shows one letter and a "Write" state can thus be
easy to miss.
If for whatever reason a grab is taken (e.g. a menu popping up) while
somebody is pressing a mouse button on an ArdourButton, then the
ArdourButton will not get the mouse button release event and will look
stuck in pressed position.
The leave notify event is fired if the mouse is still on the
ArdourButton while the grab is taken, but not if the user was dragging
the mouse outside of the button.
The only reliable way is to listen for the grab_broken_event signal.
Do so.
Make their popup menus show attached, and on mouse down, but keep the
context menu behavior on middle- and right-click for the group button
that reacted to those (probably an oversight but some users might have
got the habit of right-clicking).
This also makes the group deletion on Ctrl+click happen on mouse down
instead of mouse up which is not a great difference and avoids
complicating the code.
By passing the current text of the automation button we can make the
dropdown menu align with the current mode. This will only work for
full-size automation buttons, not when use-knob is true, but in that
case it feels wrong to popup on top of the button anyway.
Also make the menu show on mouse down like a real dropdown.
Because all uses of the function positioning menus anchored to a widget
were as callback argument to Gtk::Menu::popup() where the caller needed
to correctly bind arguments, this led to repeated and a bit obscure code.
Wrap the logic into an helper function that takes care of all that, and
update the callers.
- it is currently dual use (move both ends of a range marker
during drag / push control points at the beginning of a drag).
this may have to be separated, but as it is called the push
points modifier, it belongs here.
- audio-locked midi regions can be start-trimmed properly
when close to 1|1|0
- a midi region placed before the first meter
will continue the tempo curve and first meter.
Only a couple of callers require change, as bbt_at_beat() already
deals with this.
A peak rectangle in the mixer strip is ruled by "gtk_bright_indicator". In the previous commit I mixed up this item with "meterbridge label" & "meterbridge peakindicator". This commit changes "gtk_bright_indicator" from white to red and returns "meterbridge label" & "meterbridge peakindicator" state to primordial. So now the peak rectangle in the mixer strip will be red when a sound peak has a place.
The existing code relies on AutomationControls for getting parameter
changes and update the UI accordingly. One case where this doesn't yet
work is preset loading, where ARDOUR::Plugin is responsible for actually
loading the preset but doesn't notify the changes to AutomationControls.
Since the input_controls vector now contains all ControlUI's that rely on
AutomationControls to get updates, just listen to Plugin::PresetLoaded()
and trigger an update of all elements in input_controls.
This is temporary until a better solution is devised to make
AutomationControls aware of preset loading.
The super rapid timer was disconnected by GenericPluginUI::stop_updating
but never connected again, so the generic UI worked often without
getting periodic update triggers anyway.
Try to disable the mechanism altogether, and see if there are updating
glitches.
It makes no sense to check for the validity of mcontrol only for
controller creation, since the remainder of the code assumes that the
controller will have been created correctly.
Replace that by an assert.
That list is used to set the automation state of all automatable
controls when the global automation state is changed with the buttons at
the top of the generic UI window. The controls were added to the list
regardless of the automatable status, and some controls were even added
multiple times: once in build_control_ui() and once in build().
Since changing the state of non-automatable controls is wrong, only add
the control UI in build_control_ui() which already has the knowledge of
automatable or not.
Since it is the only case that's completely different from others in
that it only handles properties, and uses a different signal path for
updates, don't put it in the middle, but as the first case to check for.
Code move only, no behavior change (since it should be exclusive to all
other cases anyway).
The code connected the callback to the PropertyChanged signal from the
plugin once per filepath control created. Should the plugin have several
files to open, this would be at best wasteful and at worst racy.
Connect the callback a single time, since the same callback handles all
property updates that we're interested in. Also rename the methods,
members and typedefs so that it's clear what the code is trying to do.
When programmatically showing a pane, instead of directly asking the
preferences notebook to show the pane, search for the asked path in the
panes tree, and select it. Since OptionEditor listens to selection
changes in its TreeView, the correct pane will be shown, with the added
benefit that the corresponding section in the tree will be highlighted
so that the user knows which pane is currently shown.
When freq was changed to be an integer, the conversion to kHz became a
truncation. Divide by the float 1000.0 to pass the correct value to the
stringstream formatting routine.
The trim knob has been designed to operate only on audio channels. If
the bus has none, hide the knob that would otherwise have no effect at
all.
Factor the trim control show/hide code out of MixerStrip::set_route(),
and also call that code in response to I/O changes in the route.
PortMatrix is able to filter out ports that have an unwanted datatype, but
if a Bundle is added that has no port at all with a wanted datatype then
it is not weeded out correctly (and even if it were, there's no chance
that it will legitimately appear in the UI). Don't add that kind of
Bundle in the first place.
pingback comes first. We need defaults (with SSL). Later explicit
(Freesound Moocher) and implicit (curl_easy_init) calls to curl_global_init
are idempotent and won't get the flags back.
Ardour tried to make an educated guess at the initial number of outputs
for a new send. It used the channel configuration of the master bus, if
it existed, else the channel configuration of the route itself.
That guess is good in most cases, but in the case of a track/bus without
audio channels, creating a send with audio doesn't make sense. In that
case, also use the route outputs as a base for the send configuration.
The instrument dropdown can be very wide (depending on available synths)
and combined with other dropdowns and the copy-checkbox in a single row,
the min. width was well above 1400px.
In order to choose which port name to display (if any) in the button,
MixerStrip::update_io_button() first chose a primary type for the input
or output. It was AUDIO in all cases, except if the route was a
MidiTrack where the primary type was MIDI.
In the latter case, it enabled the following code of update_io_button()
to show the MIDI sources feeding the MidiTrack rather than showing an
unhelpful dash.
But this simple heuristic has several shortcommings:
- Going further, tracks and busses will probably loose strong types so
the approach is not future-proof;
- It doesn't take midi busses into account, yet there is no reason for
them to be handled differently than midi tracks;
- It falls short when the midi track contains a synthesiser and is
meant to output audio.
Improve the heuristics by choosing the data type as follows:
A) If there are connected audio ports, consider audio as primary type.
B) Else, if there are connected midi ports, consider midi as primary type.
C) If there are audio ports, consider audio as primary type.
D) Else, if there are midi ports, consider midi as primary type.
These new heuristics give the same results for audio tracks and busses
(whose audio inputs have not been removed), and the same result for the
input of midi tracks (again, provided the inputs have not been tampered
with). It improves the situation for inputs of midi busses, and output
of midi tracks and busses, especially when synthesisers are in use.
