They already worked in the PianorollMidiView, because that hands off enter/leave events
to the parent EditingContext (a Pianoroll). But MidiRegionView and Editor were
not interacting in the same way, so leaving a note object would not cause the Editor
to do the right thing with the cursor.
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
Regular .h files *should* be self-contained and independent of previous
includes and guarded to only include once. Make it clear which files
that *doesn't* apply for at all.
NoteDrag (change pitch) only works correctly for the topmost
region when using Stacked LayerDisplay. Note-grid is also only
displayed for the top layer.
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.
Copyright-holder and year information is extracted from git log.
git history begins in 2005. So (C) from 1998..2005 is lost. Also some
(C) assignment of commits where the committer didn't use --author.
Selected notes no longer show the selected color for fill, following Alex
Mitchell's proof-of-concept patch that showed it was easier to see what you're
doing when the fill color shows velocity and we just use outline for selection
status.
NoteBaseDeleted signal is static so each MidiRegionView(MRV) gets notified
about the deletion of each NodeBase instance even if it is contained in another
MRV
The NoteBase and MRV classes are currently coupled anyway, so this change uses
the reference to the MRV parent to directly call the parent when the NoteBase
is deleted. This is all in the GUI thread so I'm not sure why a PBD::Signal was
being used?
If the MRV class is the only reference holder to the NoteBase class
then I'm not sure if a callback is needed, perhaps the MRV should just remove
the note from the selection before deleting it but I'm not that familiar with
the code.
Signal emission/calls static NoteBaseDeleted signal vs direct with 10540
NoteBase instances.
static:
After Load Session: 6360638
After Unload Session: 12221026(5860388)
direct:
After load Session: 10540
After unload Session: 21080
Session Load/Unload time in master, debug/release with ~10000 Notes(seconds)
Load Debug: 32, 26
Unload Debug: 83
Load Release 32, 20, 42
Unload Release 26, 25
Session Load/Unload time with direct call debug/release(seconds)
Load Debug: 21.7, 18.1
Unload Debug: 69.4, 71
Load Release: 22.6, 13.4, 17.7
Unload Release: 24, 23.5
This is not a large Session, 1500 regions, 10000 notes so there is probably
some other funky stuff going on that needs fixing.
This commit changes some color names, nuke your theme. This isn't quite ideal
yet, but takes some steps towards where I think things should go aesthetically:
Make automation tracks/regions colors correspond to their parent's type.
Make selected MIDI notes outlined in red like most everything else, and scrap
separate min/mid/max fill colors for selected MIDI notes.
Color automation ghost MIDI notes based on original note color.
Try to kill 90's looking brightish gray gradients in general.
