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.
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
VelocityGhostRegion used the visibility of the "parent" note canvas item of a
lollipop canvas item to determine the lolli's visibility. But during the
construction of the MidiRegionView, the note's container is not yet visible, so
this fails.
In addition this logic would hide lollis for notes that are outside the current
visible note range of the track (because the parent note item was not visible).
This change adds a method to MidiRegionView to decide if a note is within the
region's time range, and if so, we show the lollipop item. This means that
lollis for notes outside the note-range will still be visible, which seems more
correct. In addition, the nascent condition of the parent note's container no
longer affects lolli visibility.
This is mostly a simple lexical search+replace but the absence of operator< for
std::weak_ptr<T> leads to some complications, particularly with Evoral::Sequence
and ExportPortChannel.
In the presence of tempo-changes distinguishing between offsets and
absolute positions is signficant. It is only valid to convert absolute
times using the tempo-map
Furthermore since GUI zoom-factor is time-invariant (samples per pixel),
all GUI operations must explictly use samples (or timecnt). It is not
valid (and problematic) to use use a location dependent timepos.
these functions operate on the _note_diff_command,
which is explicitly a NoteDiff, not a generic DiffCommand
also fix a few thinkos where the ambiguous naming led to errors
::model_changed() is used when the model has changed (eg. new notes or some
notes deleted); ::view_changed() is used when only some view parameter (e.g.
zoom, scroll, track height etc) has been altered.
Not fully functional yet (::view_chanted() ignores scroll)
When adding a note, use these criteria to choose the channel number:
* if the user has explicitly specified a note in the pulldown, use that
* if the user has AUTO selected and we are in a region, choose the nearest note's channel (consistent with velocity behavior)
* as a fallback, query the track for its channel-filter (old behavior)
