In particular, keep the MidiViewBackground's sense of the data range intact,
use MidiModel::{highest,lowest}_note(), center ranges that don't fit
on the data range
the code was first clearing the entire Editor selection before adding
the region, causing every note selection to trigger the RegionsChanged
pathway. This is crazy expensive for some reason (more than 8.12) and that
should be investigated, but the logic is also wrong. Selecting a region that is
alrready the sole selected region should not cause any action at all.
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.
If an idle data captured callback executed AFTER the code trigger by capture
end, it would call ::begin_write() which would end up calling clear_events()
which would delete all notes in the correctly setup MidiView.
Now, the idle data capture callback no longer does anything of significance if
the TriggerBox is not actively recording. In addition, we do not call
begin_write() in the MidiView if it is not already set up for capture
display (this is triggered by changes in the TriggerBox's record enable state
and the first data captured callback from an RT thread. Further,
::begin_write(), if called, only deletes notes that were in
_active_notes (though this should probably never happen).
the active notes that are extended by transport rolling are
owned by MidiView::_events, not MidiView::_active_notes, so do not
delete them when cleaning up _active_notes.
As noted in 8b389ee829, we now clear the _note_group container
before any other Note items might be deleted. But since this
may delete the _ghost_note, we have to be sure to reset
that to a null ptr to avoid a double-free later during
~MidiView
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.
