The heuristic currently used to display port connections in a
compact user-friendly way only considers Audio and MIDI data types.
Replace it by a better heuristic that does essentially the same thing
with all DataTypes, assuming they are ordered by likeliness of usage.
Currently the result is the same since there are only two DataTypes.
Trim automation is planned via SlavableAC as normal AutomationMode.
Some of this code have a revival (a special "Trim+Preview" state
before merging Automation but that has to be more general than Pan & Gain.
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.
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)
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.
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.
This allows correct reordering of the mixer "track_model" even
when non-route elements are present.
This isn't really utilized in the Editor at present because we do
not show VCAs there at all, but it will become important in the
future when we represent VCA automation there
reduce color diversity and clean up color definitions of
the monitor section: mute, solo: use mixer-colors, prefix all MS-colors
with "monitor section"
it seems that g_locale_from_utf8() (called by <<) is not thread safe,
at least not on OSX.
glib error-code 1, Invalid byte sequence in conversion input
-> throws Glib::Error.
possible fix for #6435, route-creation is interrupted via catch(...)
Previously a Midi-track with synth showed “-“ for the output
even if the audio output ports were connected. (only MIDI
connections are displayed on the button).
RouteUI::set_route() already does the right thing. Also remove RouteUI::mute_changed() since its
only role was to handle the mute change signal from a route, which boost::bind() makes unnecessary
since we can connect update_mute_display() directly.
left-click should show the simple input picker menu.
right-click shows the routing grid.
also reordered the menu to give lower precedence to {add/remove}-port
Diameter is calculated depending on font-scaling.
Besides, all explicit calls simply set the default
value, anyway. If some API is needed in the future,
it should set the diameter in [em].
This fixes issues where button text was set during static
initialization where the widget style was not yet available,
and a lot of related issues where the text was set
before style.
Always give ArdourButton a chance to handle Press or Release events if you override them.
This allows ArdourButtons to do the "Pressed" animation
And it now correctly eats the event so button clicks don't select the channelstrip.
ArdourButtons now have a "pushed" animation.
The gradient is now implemented in the button, rather than providing 2 colors in the theme, which was burdensome.
Lots of code cleanup in ArdourButton. Removed several unnecessary flags.
Refactor more stuff into route_ui.
The goal is to preserve a consistent layout and sizing of the buttons.
Button height should not resize based on text, because font styles differ and this leads to inconsistent button heights
Button width should not be based on text or font size; instead, font size just determines how many chars will be visible in the button
There are some elements of the editor page which _do_ scale based on the text width, and thats probably sensible because the text is predefined, and needs to fit
