Do that by wrapping the packed controls box in a ScrolledWindow and
making it request the same width than the box but capped to 90% of the
screen width.
Also, when the box width exceeds the maximum value, try again with
one-letter automation buttons in case the reduced width avoids showing a
scroll bar.
The generic plugin UI uses spelled-out automation state buttons for
controls, which is good for readability and usability, but some plugins
have a very big amount of controls which means we need a lot of columns.
For those plugins, prefer one-letter automation states, to save width.
When there was a knobtable in the ControlUI, the behavior of the
automation state button changed by displaying one-char state as in track
headers. Factor out that logic to depend on a new boolean property of
the ControlUI, which should be set with set_short_autostate().
This regroups sizing logic in a single place and avoids future
discrepancies between the actual caption and the size allocated for it,
when several use-cases for smaller buttons are added.
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.
Add config setting for playhead-scroll-speed.
Default to 100% for now, but for new users we might later default it to something slower.
If you want to scroll quickly, it is preferred to zoom out first, then scroll.
New function session_gui_extents() reports the extents of all playlists.
ToDo: include region playlists, when they become available.
also: slow-down autoscroll (ToDo: make a config variable for this)
When setting up the 'TemplatesImported' signal, these 2 calls appear in the c'tor for class TemplateDialog:-
boost::bind (&RouteTemplateManager::init, route_tm)
boost::bind (&SessionTemplateManager::init, session_tm)
However - '&RouteTemplateManager::init' and '&SessionTemplateManager::init' are in fact the address of the same function. This seems to be causing a problem, either for boost::bind, or MSVC (or both).
In earlier builds they were 2 separate functions. So let's put them back that way (since the current code actually crashes the compiler!!)
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.
