- first tempo is glued to first meter position as they are now
both locked to AudioTime.
- all existing audio-locked tempos to the left of the first meter
are made inactive. all to the right are made active.
- audio locked meters define an offset which is used for all public
TempoMap methods while the internal map remains contiguous.
Probably a few unexpected consequences here, but seems to work mostly.
- this helps where tempo and meter have a somewhat circular
dependency.
MetricSection now has a musical position expressed in beats (a double).
MeterSection still has a bbt, but it really isn't needed as we have
enough information to discover the number of bars at a given beat without it.
TempoSection now has a hack to enable loading of legacy sessions, which will
ultimately be a lot cleaner than the current code.
Removing bars from tempo sections also allows us to place them
at arbitrary frames (implemented here).
Replaces the list of points in TempoMap with TempoSection functions, which
compute tempo-at or tick-at time relative to tempo section start.
TempoMap consults them additively to determine things like bbt_time(),
frame_time() get_grid() etc.
This has a marked effect on scrolling speed along with the code simplification
in the places it has been attempted.
Several things are broken here.
Currently every ramp except the last one is an exponential ramp. this may
be simple to fix :).
Mouse-over midi grid doesn't match mouse click grid. should also be simple.
Many things seem to work, but their accuracy should be in question until
each area has been addressed.
I would have loved to split this apart, but there are just so many interrelated changes,
it makes little sense and would be a huge effort that would break future git bisect
use because so many intermediate commits would not compile
- add_midi_region used to commit, resulting in
_region->set_position() adding a command when there was
no current transaction. The sub-bug here was that repeatedly
calling set_position() on the new region resulted in nonsensical
automation movement after the drag.
- removes the need for 'pixel hunting' wrt NAME_HIGHLIGHT_SIZE.
- new control points generated by clicking on a line are placed
where the verbose canvas cursor says they are.
- 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).
previously if some audio region was locked and locked to video,
the audio-region always stayed put and the video could only be
moved forward.
TODO: add an "unlock all" option.
- also allow moving of automation lines in internal mouse mode.
- this is also a first pass at ensuring that if an operation does
nothing, avoid an undo entry.
- 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.
- its now possible to use snap modifiers in combination with others
afaict this hasn't worked for some time.
- use "contains" rather than "equals" during drag. Still uncertain
about this wrt beginning a drag. for now they are all "equals".
- probably solve the "snap modifier modifier" problem using
ArdourKeyboard::indicates_snap () and friend.
- Also makes "Mod4" Appear as "Windows" and adds new combination
"Alt-Windows" to the dropdown.
- Attempt to set a pair of default snap modifiers (without
knowing what it actually is for OSX)
- Copy modifier now saves
- Snap modifier modifier problem still remains.
- Copy modifier still doesn't save
- Testers please edit the Extra section of ~/.ardourN/config to allow
defaults to "take"
- Note that the current defaults overlap.
- warning - absolute snap modifier has no default and will be always
"on" unless you set it!
Note that no defaults are set - go to prefs->user interaction to
ensure that nothing is set to "no modifer"
also - the copy modifier doesn't actually save its state yet.
- user can abs/rel modifier key in prefs->user interaction
suggested for linux - absolute->alt ignore snap->alt-shift
- Constrained mode works the same as button 2 drag (initial move
sets constraint axis).
Button 2 drag now is constrained to initial move axis, removing
all modifiers from this op.
Remove Jump after trim mode.
TrimDrag now has:
Primary for trim anchored to fade.
Secondary for contents trim (as before)
Primary & Tertiary for "non overlap" trim
All drags have Tertiary for relative snap
* Handle large (delta > 1) movements into the DZ
which are not due to invalid-drop positions, but
caused by laggy GUI or rapid user movements.
* ignore busses when moving out of the DZ.
Allow to drag multiple regions from different tracks
to/from the dropzone.
Busses & Automation-lanes are ignored, as are
hidden tracks.
Any region may serve as mouse drag anchor.
fixes#6172 and #6176
Fixes#6172 and #6176 for single region drags.
Further work is needed if multiple regions on different tracks are dragged over hidden tracks
(see inline comment).
The previous code assumed that dragging up from the drop zone into the last
track is always valid. This is not true when the type of the dragged region(s)
do not match that route, which resulted in a crash and/or bizarre behaviour.
This took entirely too long to figure out, there are some real nightmares in
the region drag code...
This probably breaks some of ardour's functionality (e.g. layered mode), but seems to
be either just right or very close to it for tracks
Conflicts:
gtk2_ardour/editor_routes.cc
This does not address the visual flattening that occurs before the drop
is complete. Doing that is complex and there is no immediate solution
visible. The result after the drop is complete is correct, however.
This does not address the visual flattening that occurs before the drop
is complete. Doing that is complex and there is no immediate solution
visible. The result after the drop is complete is correct, however.
Conflicts:
gtk2_ardour/editor_drag.cc
[Details] Crash was provoked because of an attempt to add commands to the session reversible command, but when autoscroll started and trim began with autoscroll the session reversible command was not created for for Trim Drag.
Range select rect sticks around now after switching to the draw tool, but
disappears if a note selection is made. Not sure if draw is really the most
appropriate tool here (particularly if we ever implement actual pencil-like
drawing); edit contents seems more appropriate but that would probably cause
more selection issues, so here we are.
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.
The user can now replay *all* earlier selection operations until the next
session undo/redo command, or the completion of a new operation.
Nothing relating to selection ops is stored, and selection operation history
is begun on first idle.
Selection operation history is fundamentally different from the history of
operations which act on a selection in terms of both their viewport and the
amount of information required to replay them.
WRT undo, the user of a selection op doesn't care about the viewport state
at the beginning of an op, but rather that at the end of the previous one.
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.
Using _last_pointer_frame breaks when dragging to the left of the canvas, because we clamp
the value of the frame to >= 0. Motion would step once the pointer crossed the left edge
of the canvas because the frame value would always be zero.
This is not a problem when using the pointer x,y values which end up appropriately negative
under all conditions.
This lets us get a more explicit handle on time conversions, and is the main
step towards using actual beat:tick time and getting away from floating point
precision problems.
No functional changes in this one (for easier auditing), but towards having
round up/down only if necessary modes, rather than kludging around that
situation with a double round as we do currently.
It was much too easy to accidentally create MIDI regions in object mode. If
the user isn't in draw mode anyway, then even after creating a region, they
can't put notes in it, so I don't think we've lost any discoverability here.
Specifically, when pivoting from forwards to backwards (around the drag start
point), the note length was too long. Setting both the start and end x
coordinates of the rect every time to the right value does the right thing.
Use RegionSelection for MIDI regions as well, since the old dumb stub didn't do
some things correctly. There's probably no reason to have a separate class for
this at all, and some good ones for putting all regions in the same selection,
so we should probably do that. For now they are still separate in the
selection but use the same base class.
TODO: needs undo. only works in top quarter of automation lane. selection model feels weird sometimes. needs to show gain curve when you are using Range tool
