This lets us get a more explicit handle on time conversions, and is the main
step towards using actual beat:tick time and getting away from floating point
precision problems.
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?
No functional changes in this one (for easier auditing), but towards having
round up/down only if necessary modes, rather than kludging around that
situation with a double round as we do currently.
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.
This cleans up a lot of false-positives in static analysis
and also helps compilers to optimize code paths in general.
(tagging the fatal stingstream operator as ‘noreturn’ is
far less trivial)
the documentation was correct: “GTK+ uses G_PRIORITY_HIGH_IDLE + 10
for resizing operations, and G_PRIORITY_HIGH_IDLE + 20 for redrawing
operations.” but the priority for the idle visual changer was wrong.
fixes, follow-playhead and zoom/scrolling under load (no idle)
* retain [custom] track-height
Editor::override_visible_track_count() is called repeatedly (for
every change), there was a 50/50 chance of it saving the right value.
* adjust default for new sessions: use “Normal” track height until
told otherwise.
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.
Consistent mixer strip button height.
The latter works by setting all the button size request heights to the
calculated height of the alphabet. Thus, all buttons of the same class will be
the same height regardless of their actual text.
All the different looks here didn't seem to convey anything useful to me, and
looked sloppy. I went with the style of the transport button.
It would be nice if we could style button elements like Inset in the
configuration, but this would require some work.
move toolbar box above editor-canvas. Without-editor mixer
there is no change. With Editor-mixer it is now above the
mixer-strip.
This makes the toolbar [almost] fit on 1024px width.
