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.
cursor icons squared with north-west gravity.
hotspots are identical to original icons.
otherwise gdkcursor-win32 creates square cursors with
center gravity and hotspot X/Y differs.
Fix some inaccurate/misleading comments that led to said bug.
Gracefully handle the "impossible" case where we can't figure out a state ID
for an automation track, instead of crashing.
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?
This should probably hijack the same modifier as the guard points and work the
same on all automation tracks, but I did it this way to not change behaviour of
track automation where a default is much more reasonable.
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.
We shouldn't have to manually drive the drag here, but if the ARV handler
returns false, the event doesn't propagate correctly for some reason and the
drag is not driven by the Editor.
Two issues:
1) AutomationRegionView not receiving events (CC breakage).
2) Entered values must be rounded to integer for MIDI controllers. This should
be done more generically with ParameterDescriptor for all controls (also
supporting boolean toggles and such), once ParameterDescriptor becomes more
pervasive and takes over Evoral::Parameter, but this will do for now.
It was much too easy to accidentally create MIDI regions in object mode. If
the user isn't in draw mode anyway, then even after creating a region, they
can't put notes in it, so I don't think we've lost any discoverability here.
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)
Specifically, when pivoting from forwards to backwards (around the drag start
point), the note length was too long. Setting both the start and end x
coordinates of the rect every time to the right value does the right thing.
This makes for extremely confusing behaviour, particularly when creating new
regions. This is still probably too transparent, IMO, but at least isn't
totally mysterious. "visible" is a bit of a misnomer in the code, now.
Use RegionSelection for MIDI regions as well, since the old dumb stub didn't do
some things correctly. There's probably no reason to have a separate class for
this at all, and some good ones for putting all regions in the same selection,
so we should probably do that. For now they are still separate in the
selection but use the same base class.
Show fancy values on generic GUI controls, automation lane controls, and automation lane verbose cursor.
Fix text display of midiNote values.
Make bigstep of midiNote parameters 12 (one octave).
Add ARDOUR::value_as_string() as a stateless one-stop-shop for value printing.
Prepare to allow BarController (with Spinbutton) to translate
internal/interface values for the SpinBox.
(The change is irrelevant for the fader/slider itself which
always use the [user-]interface value)