-
Notifications
You must be signed in to change notification settings - Fork 659
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFC: Automation control point operations #744
base: master
Are you sure you want to change the base?
Commits on Sep 18, 2023
-
Larger and transparent automation control points
The control points were very small and hard to spot, especially when painted on top of waveforms. Also, the snap size for automation lines were bigger than for the control points at the end, making it hard to click the control points. Fixed by making the control points twice as big - that seems to match the size of the automation line snapping. To avoid control points showing up as too big solid blocks blocking too much, we stop making them filled. The bigger outline is more visible than the old solid block.
Configuration menu - View commit details
-
Copy full SHA for 1156828 - Browse repository at this point
Copy the full SHA 1156828View commit details -
Reorder ControlPointDrag::motion to prepare for the next change
A pure refactoring.
Configuration menu - View commit details
-
Copy full SHA for 63ee95e - Browse repository at this point
Copy the full SHA 63ee95eView commit details -
When dragging automation points, only drag horizontally or vertically
The most common drag operation on an automation point is with the intent of either moving it in time or in value. That was very hard to achieve when both dimensions were free. Slightly similar to "Ignore Y-axis when adding new automation-points", we thus "snap" the move to either being horizontal or vertical. In the rare occation where we want to move in both dimensions at once, we can still and fully intuitively do that with 2 drag operations.
Configuration menu - View commit details
-
Copy full SHA for 0d99285 - Browse repository at this point
Copy the full SHA 0d99285View commit details -
Refactor to let Editor::can_remove_control_point take a ControlPoint …
…reference Avoid retrieving control_point from Item both in Editor::remove_control_point and in Editor::can_remove_control_point . remove_control_point is called from Editor::button_release_handler, and is very view-ish, so it is fine that it takes an Item. can_remove_control_point is slightly more low level and model-ish (almost so much that it could live in AudioRegionGainLine), so it kind of makes sense that it works on the ControlPoint. There is no extra code. The retrieval of ControlPoint moves from can_remove_control_point to Editor::popup_control_point_context_menu . This refactoring will make it easier to implement deletion of multiple selected points.
Configuration menu - View commit details
-
Copy full SHA for 80d6aa1 - Browse repository at this point
Copy the full SHA 80d6aa1View commit details -
Allow removing multiple control points
It was surprising that removing on multiple selected control points only removed one of them. This allows selecting multiple points by dragging a box or Ctrl-clicking, then removing all from the context menu of one of the points. Some more trivial implementations of this suffered from problems when deletion of control points in the model also invalidated the iterator over selected control points.
Configuration menu - View commit details
-
Copy full SHA for dda27cd - Browse repository at this point
Copy the full SHA dda27cdView commit details -
PoC: Implement += -= *= /= for control point editing
For example, if editing a control point at 7 dB and entering "+= 3" in the input field instead of "7", it will set the control pointto 10 dB. This is especially useful when editing multiple automation points at once.
Configuration menu - View commit details
-
Copy full SHA for 4c8e2b7 - Browse repository at this point
Copy the full SHA 4c8e2b7View commit details