Each MidiRegionView(MRV) is connected to the Selection::ClearMidiNoteSelection
signal that is used to notify the all MRV instances to clear their note
selection.
The MRV class also has a private static SelectionCleared signal that is used to
signal other MRV instances when their selection has been cleared. When the
Selection::ClearMidiNoteSelection signal is emitted it causes each MRV to also
emit the SelectionCleared signal. So the emission takes quadratic time.
With 1500 MRV instances emission takes about 2.2 seconds on my machine, and
some operations like track selection cause it to be emitted 3 times(another
issue).
The Selection class in the Editor knows which MRV instances have note
selections, as it is notified by MidiRegionView whenever the selection count
becomes zero or becomes non-zero. Clearing the Note selection should then just
be O(N) and direct calls can be used rather than signals.
This change removes both the signals and uses the existing references between
Selection and MRV class to control note selection. There should be no
behavioural changes in Midi note selection with this change.
Playlist::_split_region copies the region and BBT_Time member is default
constructed so position is bar 1 beat 1.
The regions sample position is then initialized to the new position using the
property list.
Playlist::add_region_internal is then used to add new regions to the playlist
which calls region->set_position() but as the region position has already been
initialized it does not recompute the _bbt_time member based on the new sample
position.
Then when a tempo change occurs and Region::update_after_tempo_map_change is
called the default initialized _bbt_time member is used to incorrectly
determine the new sample position.
So the change removes the initialization of the new region position using the
property list initialization method and just lets the playlist set the position
of the region in Playlist::add_region_internal so that the region _bbt_time
member is recomputed in Region::set_position_internal.
This one is debatable, but since we know that the filter method is const with respect to the AUPluginInfo
object, the const_cast<> seems like the simplest AND cleanest solution
