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)
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)
the rest from `tools/convert_boost.sh`.
* replace boost::function, boost::bind with std::function and std::bind.
This required some manual fixes, notably std::placeholders,
some static_casts<>, and boost::function::clear -> = {}.
