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.
For some reason, grabbing the magic keyboard focus makes scroll stop working
regardless of what MRV::canvas_group_event() returns. I can't figure out any
reason to grab the keyboard in this case anyway, so I just removed it.
Also simlify MRV event handling code in general.
The idea here is to do the reasonable thing, and copy objects of some
type (e.g. MIDI region, gain line) to tracks with a matching type. The user
can override this with a track selection, which will be used straight-up.
Lost: ability to copy/paste lines across types, e.g. gain to pan. This is
often questionable, but sometimes useful, so we will need to implement some
sort of "greedy mode" to make it possible. Implementation simple, but not sure
what to do. Perhaps this should only be possible if one automation track is
explicitly (i.e. via track selection) involved, and the types are at least
compatible-ish?
This should probably hijack the same modifier as the guard points and work the
same on all automation tracks, but I did it this way to not change behaviour of
track automation where a default is much more reasonable.
We shouldn't have to manually drive the drag here, but if the ARV handler
returns false, the event doesn't propagate correctly for some reason and the
drag is not driven by the Editor.
Two issues:
1) AutomationRegionView not receiving events (CC breakage).
2) Entered values must be rounded to integer for MIDI controllers. This should
be done more generically with ParameterDescriptor for all controls (also
supporting boolean toggles and such), once ParameterDescriptor becomes more
pervasive and takes over Evoral::Parameter, but this will do for now.
Remove Canvas::Layout, use Canvas::Container for the same purpose, move child-rendering into Item::render_children() so that it
could theoretically be used by any derived type.
It's slightly possible that this causes trivial build failures on different
configurations, but otherwise shouldn't cause any problems (i.e. no actual
changes other than include/naming/namespace stuff). I deliberately avoided
removing libardour-config.h since this can mysteriously break things, though a
few of those do seem to be unnecessary.
This commit only targets includes of ardour/*.h. There is also a very large
number of unnecessary includes of stuff in gtk2_ardour; tackling that should
also give a big improvement in build time when things are modified.
git-svn-id: svn://localhost/ardour2/branches/3.0@12420 d708f5d6-7413-0410-9779-e7cbd77b26cf
