| Age | Commit message (Collapse) | Author |
|---|
|
selection"
1. Alt is still handled to change drag behavior
2. Selection doesn't store notes unless they are part of the cut buffer, which means we should not
be altering the note selection in the editor's selection object most of the time.
|
|
|
|
|
|
|
|
That's with doxgen 1.8.13.
|
|
|
|
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.
|
|
|
|
|
|
Generated by tools/f2s. Some hand-editing will be required in a few places to fix up comments related to timecode
and video in order to keep the legible
|
|
make libwidget independent of libcanvas.
Confine basics to pbd and gtkmm2ext.
|
|
|
|
|
|
- should fix 7105
|
|
- wysiwyg (during drag) when dragging more than one note across
a tempo change.
- introduces a muscal equivalent of snap_delta (only used for
note drags atm)
- split earliest note in selection into a separate function
- MRV::copy_selection() returns the equivalent _primary note
to avoid offset hell.
- RV::snap_frame_to_frame returns a MusicFrame
- prevent note drag moving before region start.
|
|
- don't add a new SysEx canvas item every time we zoom or drag.
- speed up redisplay generally using PatchChange-like method
for finding items (find_canvas_sys_ex() in boost::unordered_map).
|
|
- as MRV removes invalid notes from the GR, we
can simply update all events after checking vertical visibility.
|
|
Probably some corner cases to be fixed, but pretty functional and largely modelled
on existing code (paste, drag, step add note etc.)
|
|
use boost::unordered_map as a note store for ghost & midi region
views.
as per otiginal method, only notes within regoin bounds are stored.
|
|
- also fixes patch changes appearing outside region bounds
when copied/trimmed.
|
|
|
|
- zoom is still a bit slow.
|
|
|
|
- this allows a midi region drag to update the visible notes
correctly while crossing MIDI streamviews with a differing
note range.
as a side effect, fixes a bug where changing
note range on a track did not draw some notes
(apply_note_range redisplays the model).
|
|
|
|
entered.
|
|
|
|
- NoteCreateDrag already applies this shift, so it was
always applied twice to the note start frame.
|
|
- also ensures poiinter ghost note respects the snap modifier.
|
|
drag.
|
|
this simplifies lua-bindings and also let's the compiler worry about
constant primitive types.
|
|
ctor.
|
|
Also fixes it so the key is selected in the piano roll header
|
|
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.
|
|
|
|
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.
|
|
|
|
|
|
- also clean up, rename and comment some previous hanges.
|
|
|
|
- remove "no_magnets" ugh.
|
|
|
|
|
|
This is debatable, the "sustained until mouse release" behaviour is handy
sometimes, but this way seems like what most people probably want.
Also, this "fire it and forget it and let it delete itself a bit later" thing
with MidiPlayer makes me nervous. I guess it's unlikely someone manages to
select a note then delete a track within 100ms, but, well...
|
|
|
|
Fix several other cases where a single mouse click could cause several
(not nested) selection ops.
Fix missing selection memento for midi notes and midi commands.
Rename some variables.
Fix random style issues.
|
|
|
|
... almost. There are some artifacts when you zoom out while recording that I
can't figure out, but whatever.
Also fix performance issues caused by last attempt at rec display while zoom.
|
|
|
|
|
