- for those not in the know, this series provides a way to
remove the temporal distortion introduced when using an
audio frame-based gui for music-locked objects.
In short, the gui uses an audio frame representation to move
objects. It displays the object using frame_at_beat(), quantizing
the time value to audio frames. This is fine until the user selects
that frame but expects it to be interpreted as a beat.
Thus beat_at_frame() would not produce the user-expected beat
(temporal quantization error of up to 0.5 audio samples).
This is one method of mapping audio time to music time accurately.
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.
opening a recent session from a session can result in: Editor::constructed
and session_loaded() being true. A partial instant_save can occur (not
to mention: invalid XMLnode iterators)
This functor/closure is responsible for stealing focus from any existing text entry (or whatever else may have focus)
when clicking on a CairoWidget or derived class.
The old implementation just gave focus back to the editor canvas. The new version walks up the widget packing
heirarchy to find a focusable parent (from the CairoWidget for which it is invoked). If no focusable parent
is found, it cancels keyboard focus in the toplevel window containing the CairoWidget
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
'Cut time' implies that the cut timeline items might end up on the
clipboard to be pasted somewhere: this isn't the case at present, so rename
the functions, class, &c. to say 'remove' rather than 'cut'.
Rename insert_time_dialog.{cc|h} to insert_remove_time_dialog while we're
at it.
Add options to move glued & locked markers to Editor::cut_time(), in line
with the insert_time() implementation.
Fix up the order in which operations apply to range marker start & end
points, to avoid problems when a range which lies after the cut point is
shorter than the length of the cut.
Copy the 'Cut time' code from Mixbus, making a few obvious fixes to work in
A3 (e.g. nframes_t => framepos_t / framecnt_t).
Seems to work to move & remove markers, tempo & meter markers, and regions on
selected tracks.
Still TODO:
- use existing A3 'Insert time' dialogue
- make it respect 'No selection = all tracks'
- rename the command to something like 'Remove time' or 'Delete time': 'Cut'
sounds to me as if the removed range should end up on the clipboard ready
to be pasted somewhere, which of course it doesn't.
Remove the is_xrun parameter from Editor::mouse_add_new_marker(), and just
create the marker directly in ARDOUR_UI::create_xrun_marker(), so that xrun
markers don't become automatically selected when they appear.
Achieve this by adding a new hscroll group just for cursors.
That requires a slightly smarter window_to_canvas() to deal with overlapping
sensitive scroll groups. New rule is that scroll groups can overlap, but the
most sensitive one found from the top down will be chosen to translate
coordinates. This basically means don't overlap scroll groups with different
sensitivities.
In the presence of scroll groups, having a canvas-wide window_to_canvas()
and/or canvas_to_window() fundamentally makes no sense. At some point in the
glorious future we should kill those and use only item-relative coordinate
translation.
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.
Idea here is for importing large multi-track MIDI files to be immediately
listenable upon play without tediously adding a ton of instrument plugins
manually.
For example, if you're in a note and something about the mode changes, it's the
underlying region context that needs to change. So, seems we need a stack of
entry contexts to deal with this sort of thing.
Switching in/out of smart mode still doesn't update immediately because we
don't have the y-coordinate needed to update it.