RFC: Automation control point operations
The goal of this PR is to make automation editing more smooth. Nothing big, but some workflow improvements I would enjoy.
See the individual clean changesets.
I think some of the changesets are good, ready to be cherry-picked.
I would like some feedback on whether these changes operate on the right levels, or if I violate some MVC-ish or code structure pattern that I haven't realized? For example, it would be nice to pass model objects to AutomationLine::remove_points instead of Items or ControlPoints ... but that doesn't seem to fit in.
More experimental: Make it possible to enter operands like "+= 3" when editing (multiple) control points to increase them all with 3 dB. This could be an advanced feature, documented in the manual but not cluttering the UI.
I notice elsewhere "postfix the edit with '+' or '-' to enter delta times" - that scheme should perhaps be used instead of '+=' etc ...
I';m not sure why we let this one slide. Any chance of the conflicts being resolved? Apologies ...
@pauldavisthefirst Can you help speeding it up by briefly answering some questions that came up while cleaning this up:
From a UI and implementation point of view, what is the big difference between GainLineItem. AutomationLineItem, and ControlPointItem. The code shows many differences in details, but it is hard to spot the big conceptual difference that explains the difference in implementation.
Also, what is the status / intent with Del key support? Conceptually, I assume Del works on the active selection ... with elements that might be of the same kind, or at least have a lot in common. How to hit the code path that works? I assume it would be nice if it worked more consistently so it never was necessary to use popup_control_point_context_menu to delete control points, but also the primary goal is to avoid introducing regressions..
- Re: GainLineItem. AutomationLineItem, and ControlPointItem : the first two are the line itself drawn for automation display, the former being solely for region gain (within audio regions) and the latter being for all other automation lines; the 3rd one is any canvas item used at the location of a control event
- I'm going to defer this PR till post-8.0 ... some of the commits have been implemented in other ways and some of the others need preference items, but we're in a string freeze.
I agree to land things like this early in the development phase, rather than last minute.
I will revisit after 8.0 .
Is it possible to label this PR post 8.0 or something easy to see what the agenda is for it ?