'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.
When inserting time and moving a range marker, move its end first, before
moving its start, so that if the time being inserted is greater than the
length of the range, we don't try to set its start to after its end.
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.
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.
This is a somewhat wacky workaround but no there is
no better solution in sight.
Related bug:
select range, save, quit, restart & re-load session
-> range selected but tool == object
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.
Preserve alignment between notes and control points when doing an internal
copy/paste of both.
Relative alignment between points on multi-paste is still not preserved. Both
behaviours here are actually useful, perhaps a modifier...
This doesn't seem to have been touched for years, and I don't see how such an
obvious bug could possibly have been around for so long, but, well, this fixes
it as far as I can tell.
For things like copying from pitch bender to a CC.
Also things like fader to pan, but that seems a bit funny. The conversion
probably needs to be a bit smarter here, perhaps taking the normal into
consideration...
Also push the increasingly unwieldly paste parameters into a context object.
As with othe things, currently it is only possible to do "cross-type paste" by
explicitly selecting the target track. We will need to get automation region
view selection working to do better here, but at least for now it's possible to
get the data over.
Among other things, this means that automation controls/lists have the actual
min/max/normal/toggled of parameters, and not those inferred from the Parameter
ID, which is not correct for things like plugin parameters.
Pushing things down to the Evoral::ParmeterDescriptor may be useful in the
future to have lists do smarter things based on parameter range, but currently
I have just pushed down the above-mentioned currently used attributes.
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.
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?
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.
