This includes note heights, note positions, contents height
for streamviews, positions of tracks. It makes zero sense to think of these as
having potentially fractional positions.
In addition, fractional note heights and positions lead to numerous
errors drawing MIDI stuff at the pixel level.
trim_front_(starting|ending) must be in a class derived from RegionView,
which MidiView is not.
This ensures that Carl's original design for this (with these two methods
called at the start and end of a front-trim drag) is still operational, and we
do not end up with MIDI regions that have a negative start value.
the split_info for a MidiView would stick around across note selection
operations that really should act as a "boundary" or end of the
split op. This commit ends the split op any time selection is cleared
or notes are added to the selection (except when in the middle of a split
Found via `codespell -q 3 -S "*.pdf,*.po,./.git,*.tosc,./waf,./share/patchfiles,./libs,./msvc_extra_headers,./share/web_surfaces,*.patch" -L acount,addin,ane,ba,buss,busses,caf,capela,devine,disconnectin,discreet,doubleclick,envolution,filetest,fo,ghandi,homs,hsi,layed,maschine,mis,nd,ontop,pass-thru,removeable,retrn,ro,scrollin,sectionin,seh,siz,sord,sur,te,trough,ue,wth`
It appears that mouse handling in MidiRegionView (now moved into MidiView)
predated the full Drag formalization. This led to inconsistencies as parts of the Drag
formalization were adopted, including the use of motion events to start a drag (this
is incorrect in the current semantics of a Drag).
This commits removes all/most of the special purpose drag handling machinery in MidiView
and uses Drags instead
in particular, rename MidiView::canvas_group_event() to
avoid confusion with TimeAxisViewItem::canvas_group_event()
since a MidiRegionView inherits from both these classes.
MidiCueView needs an _active_notes array setup when it is assigned a track that is
already rec-enabled, because we can start clip recording without session record-enable
being active.
MidiRegionView does not need this; it uses session rec-enable status to create or delete
_active_notes (also transport stop, sometimes)
This also only uses the draw length parameter if no motion
occured during the NoteCreateDrag. Otherwise it uses the length that was
dragged (which is subjected to a threshold).