This involved a significant change in event handling for automation region views,
but it brings it into line with how it works for other things. On button press
we initiate a drag, then if no motion occurs, the Drag returns false during
finalization, and only then do we continue through Editor::button_release_handler()
to eventually end up in ::add_automation_event().
Although it is a substantial change, the fact that it now works the same
way for audio regions, automation regions and automation tracks seems
like a definite plus.
This is a tentative change and if it proves unwise we can back it out.
I just find it awkward to have to change modes to draw when it is
completely obvious whether I am drawing or not.
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.
Change assumption that the "pos" argument to AutomationRegionView::add_automation_event is region-relative, by
making it global.
This did not affect non-MIDI automation because that used
AutomationTimeAxisView::add_automation_view() instead.
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.
In case of MIDI CC/Bend/Pressure etc events, the underlying
data is provided by a MidiTrack (is-a Automatable) and not
an automation-control.
When directly calling AutomationControl::set_automation_state,
the AC disables automation-watch using shared_from_this().
With the Evoral::Control used for MidiTrack event-lists this
results in a tr1::bad_weak_ptr.
This is in preparation to always show a line, which show
the current value in case there are no automation points yet.
It also unconditionally snapshots the current value without
changing automation modes to touch/write first.
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
This fixes copy/paste of MIDI automation (time-unit: beat) from/to
Parameter automation (time-unit: samples).
It also fixes repeatedly pasting with tempo-ramps: pre-multiply length
before converting to samples.
- 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.
- object mode: select a MIDI region that has CC automation.
Move the mouse over a CC automation event,
then press backspace to delete the selected region
- the recipe is mentioned in #7049, but seems unrelated.
- disallow simultaneous events via ControlList::editor_add ()
- clicking on an automation line selects the points that define it.
- don't 'flash' a region selection when using mousedraw mode.
- cp click selection resembles region selection.
- region gain points respect snap modifier (a la automation points).
- don't keep setting/unsetting write pass when transport frame
remains the same (think larger jack buffer sizes)
- insert guards are now 64 frames after when.
- refactor previous approach.
combines selection related editor properties with the current editor selection.
The related editor properties are:
mouse mode,
zoom setting,
left frame of the canvas,
y origin of the canvas.
Selection state now includes region views (storing the underlying region id)
and time.
This patch also fixes a region mute undo bug.
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.
Perhaps debatable if contents should be edited when not in internal mode
whatsoever, but consistent with audio region gain and track automation. It's
less of a problem with the draw tool than, say, object since drawing stuff is
its entire purpose.
Paul Davis
Robin Gareus
nick_m
Tim Mayberry
David Robillard