In layered mode the scroomer is not usable with stacked MIDI regions.
Ideally we'd only hide it if there is more than one layer
but that is for another day.
This add support for special-cased automation controls
(Fader, Trim, Panner, Mute) and spills their automation-lane
on touch.
It also features a small internal API update directly mapping
CheckMenuItem. See also bd8c26a059
This allows to re-use playlist editing in all RouteUI derivatives,
not just the main editor time axis header.
The change is mostly a NO-OP, simply moving methods from
RouteTimeAxisView (is-a RouteUI), to RouteUI.
See also 72af571f0c, ATAV for Processors cannot be identified by
Parameter alone. STAV uses a std::map<Evoral::Parameter, ..>
that is only valid for unique parameters.
The map cannot store Evoral::Parameter(PluginAutomation)
because it its not unique.
7434478a35 introduced a race, IOchange triggers updating the
GUI and re-configuring processors. The latter needs to complete
first, otherwise Track::n_channels() returns the previous
channel count.
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.
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.
This adds explicit delete calls for menus where there is a
member variable reference to the Menu.
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
* add an abstract StripableTimeAxisView (Route TAV + VCA TAV)
* move common strip-methods into STAV
* Add Automation Lanes to VCA TAV
* Allow ATAV without Automatable for VCA Controls
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.
preparation for further Summary and Number of visible
track count fixes.
* “Only Self”: don’t resize child-views (old default)
* “Total Height”: distribute height equally among
all visible child [automation] lanes
* “Height per Lane”: given height should be applied
to all sub-views.
Also push the increasingly unwieldly paste parameters into a context object.
As with othe things, currently it is only possible to do "cross-type paste" by
explicitly selecting the target track. We will need to get automation region
view selection working to do better here, but at least for now it's possible to
get the data over.
The idea here is to do the reasonable thing, and copy objects of some
type (e.g. MIDI region, gain line) to tracks with a matching type. The user
can override this with a track selection, which will be used straight-up.
Lost: ability to copy/paste lines across types, e.g. gain to pan. This is
often questionable, but sometimes useful, so we will need to implement some
sort of "greedy mode" to make it possible. Implementation simple, but not sure
what to do. Perhaps this should only be possible if one automation track is
explicitly (i.e. via track selection) involved, and the types are at least
compatible-ish?
The idea here is that pasting several times to the same location doesn't make
sense. Instead, the paste is appended past the last paste, snapped to the
grid. This make it simple to replicate a given section a number of times,
simply by copying once and pasting several times.
This behaviour only appears when successive pastes are done to the same
location (whatever the edit point is). When the paste point changes, the
"multi-paste" state is reset.
Boots 'n cats 'n boots 'n cats.
