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.
Another consequence of fuzzy Sequence timing, but if the difference is less
than a tick this should handle things correctly. If the difference is more
than a tick, something's wrong, and it might be okay to just bump forward
anyway, but I can't reproduce this and it could lead to corruption so I'm
leaving that case noisy.
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.
