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.
NoteBase-derived note objects must delete their children, because
often they are deleted long before the parent (group) is. However,
in MidiView::clear_events() we used to call _note_group->clear (true)
first, which would delete the canvas items owned by these objects,
without them knowing about it. This made it dangerous for them
to delete those same items in their destructors.
This reverses the ordering so that NoteBase objects are deleted first
(along with their canvas items) and after that we clear _note_group
which will address any danging canvas items created there that are
not owned by a NoteBase-derived object
For some reason, we allow users to trim notes on the timeline when in
draw mode. Not sure why. We don't allow this in pianorolls, so make
sure the cursors don't suggest otherwise
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
this needs more investigation but we need to return false from
scroll event handling in order for stuff to work. this should
not be the case and this will likely be reverted once the reason
it is required is uncovered
This method did not do what its name suggested. Replace it with
::absolute_time_to_source_beats() which already existed and
computed the same result.
Also in a NoteCreateDrag, correctly adjust note start
depending on whether we are viewing the whole source or
just the region. This part may be amended later.
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`
Note that for now, this leaves save/restore of the value to the time axis view, and doesn't alter
the fact that the MidiTrack represented by the axis view continues to have its own note mode too
Clip editors show the entire source contents, which alters the conversion
process needed for dealing with pixel/length/duration values versus the
situation when only showing a region (as on the timeline)
