This is an effective NO-OP
* Some methods have been re-named to improve consistency
* Duplicate function calls were removed:
RouteUI::set_route() already updates mute/solo
MixerStrip does not have to update it again
* virtual methods have been protected
This is required to toggle the strip to revert from aux-view
to the main route using the aux-send processor itself.
Discuss:
Perhaps this should be reverted, and ProcessorBox::edit_aux_send()
be removed: It is currently possible to create various
inconsistent mixer-states.
* use "Aux" on a Bus, then double-click some Internal-Send to
revert strips. But Aux remains active
* Removing sends while "Aux" is active does not disable Aux.
If the processor box was insensitive those issues won't be present.
However it is convenient to use double-click on the editor-mixer to
access a send's panner ...
* Use a single method to set mixer-strip widget sensitivity
* Update context-menu to only allow show actions that can
currently be performed, depending on active/inactive state.
* Mark all control elements of in-active strips as insenstive
except those required to re-enable the route.
* Also update processor-box and solo-button when showing Aux
Special case Mixbus. Mixbus already shows a "Insensitive" label,
and Mixbus-channelstrip element sensitivity remains to be
implemented before using this mechanism.
This was based on Ardour-5 style "set custom latency of the IO", and
inform, override JACK-port latency compensation.
Ardour6: IO itself is no longer in control. This is abstracted by
IOProcessor.
In any case, this is to be superseded by bundling a-virtual-latency,
and allowing track playback offset (that has no additional
thru-latency for cue-monitoring).
Copyright-holder and year information is extracted from git log.
git history begins in 2005. So (C) from 1998..2005 is lost. Also some
(C) assignment of commits where the committer didn't use --author.
This removes all additional GUI side meter-type state.
The route's meter-processors is now responsible for providing
the type.
meter-type is now implicit for GainMeter, LevelMeter used by
meter-strips and mixer-strips.
A Gtk::manage()d widget will be deleted when its parent container
is destroyed. Top-level context menus are not inside a container and
hence need to be manually deallocated.
The solution here is to use a shared Gtk::Menu pointer that is
centrally de/re-allocated.
This works because the GUI is single-threaded and at most one
context menu is visible at a time.
This fixes various MS related action sensitivity issues, as well
as action-states.
Also manually adding a monitor-section to a session now always
immediately shows it, regardless of prior ToggleMonitorSection
visibility.
Add Mixer-specific view keybindings for list, vca, mon. (thanks to: the_CLA)
Move monitor keybindings (mute, dim, mono) to be globally-accessible.
Implement new mixer-specific actions to show/hide monitor,vcas,mixbuses (the_CLA)
Move monitor funcs (mute,dim,mono) to globally-accessible actions.
Make a new Monitor group insted of using Transport group.
Allow use-monitor-section to be controlled by both menu and session-options dialog.
- remove trailing whitespace
- remove space after opening brackets and before closing brackets
- add space around operators
- do not use '//' for multi-line comments, do not use "//" on line-start
to comment-out code breaking indenting (-Wmisleading-indent)
- do add a single space after comment-start /*{SPACE}... or //{SPACE}...
- reserve duplicate whitespace " " for alignment, remove other duplicate
whitespace
- use established "TODO" and "XXX" (highlighted keywords)
- remove equal-sign series "====" (those indicate merge conflicts)
Generated by tools/f2s. Some hand-editing will be required in a few places to fix up comments related to timecode
and video in order to keep the legible
Check, in order, if the io is connected to another Ardour route, then a
user bundle, then some physical ports with simple configuration, and
lastly another client.
Before, Routes were considered connected as long as every io port
connected to that route, even if the channel order was mixed or worse if
all ports were connected to the same channel. Now Routes and Bundles are
considered connected if they are exclusively connected, in the right
order, to all their ports with matching datatype.
If a bundle was already connected, a click on the corresponding entry
disconnected it, essentially giving toggle semantics to the io menus.
This behavior has three problems:
— When clicking on a not yet connected bundle, the new bundle replaces
any already connected one. This is not consistent with a toggle mode.
— It is a less discoverable and less easy way to disconnect a bundle
than the already present "Disconnect" menu entry.
— Bundles that match the I/O channels only partially (recently added to cater
for e.g. MIDI+STEREO tracks connecting to Master) are never
considered "connected" because the channels are not connected 1:1.
Those will thus never toggle, making the behavior inconsistent.
Change the semantics to ensure a bundle is connected on click instead.
Ensure the master bus is the first proposed bundle if it is present.
Also propose internal route inputs before physical outs or other
software via JACK.
Last, but not least, add to the menu not only exactly matching bundles,
but also bundles that have the same number of channels than the route
output when considering only the DataType we think the user wants to
use. This covers both the case of a MIDI+STEREO instrument track
connecting to master, and the case of a STEREO track connecting to a
MIDI+STEREO vocoder track.
Avoid proposing the monitor section in the list if the current route is
not the master bus. Also allow the caller to pass a DataType as argument
to allow partial bundle match on that datatype only.
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.