|
|
I see this is an intentional change: commit 22deebb42fa32e618ddfb9fbdaa93449a57b1717 Author: Ben Loftis <ben@harrisonconsoles.com> Date: Tue Feb 12 10:29:03 2019 -0600 Selection-after-split behavior (gtk2 part) * When splitting in MouseObject, entered_region should get priority over selected regions. This fixes the unexpected case where you try to split an unselected a region, but a) nothing happens OR b) some other region (maybe off-screen) is split But I question the logic and consistency here. The behaviour makes it awkward to split regions in a lower layer which is often used when editing with the "later is higher" editing model. It also seems strange and confusing that this behaviour is specific to the Mouse Edit Point. Attached is a patch to only prioritize the entered_regionview if it does not overlap a selected region at the edit position. |
|
|
Yes, this change was made intentionally for the Mixbus commercial product. It has been released for about 15 months. The intent was to address complaints like "I am finding splits in my regions that I didn't make". This was found to be the result of users expecting the Object tool to work on the "highlighted" (entered_region) region, but instead it was operating elsewhere. Either in lower layers that were current invisible, or in regions on a different track. Since this change, I don't recall any reports of that problem. If you want to split multiple regions as you've described, there are 3 good tools for that: The Cut tool, the Range tool, and EditPoint=Playhead (all of which can use a track selection). Those operations work on the whole layer stack. |
|
|
Thanks Ben, I appreciate the response and recognise that this is unlikely to change :) However if I may at least request a configurable option for this behaviour? Consider the attached screenshot as an example. In this situation virtually every action in the Region menu (via keyboard shortcuts) operates on the selected (red) regions [Audio-1.1, Audio-1.23]: trim start and end, boost/cut gain, set fade in/out, mute, raise/lower etc. Except Split, which now operates on Audio-1.24 - a region visually distinguished only by the fade handles, not really "highlighted" (perhaps this is different in Mixbus?). I guess I don't quite understand why a user would have selected regions and NOT want the action to operate on them. Regarding your suggested alternative tools: - The Cut tool is not able to take a region selection so will not help in this situation - The Range tool will split all the layered regions, not just the selected regions - Yes, using EditPoint=Playhead does work as expected, but requires changing to a different editing model and loses the efficiencies of EditPoint=Mouse. split-situation.png (89,992 bytes) |
|
|
I think "entered_regionview should only be prioritized if it does not overlap a selected region at the edit position" as proposed by the patch is the best of both worlds. @BenLoftis this should still prevent your "I am finding splits in my regions that I didn't make" issue. If a selection is elsewhere, entered_regionview is used. Am I missing something? |
|
|
TBH this still seems pretty messy to me - it's not logical why the Split action in particular should be special-cased to behave differently. Perhaps what @BenLoftis‘s user really wants is an additional mouse mode (or sub-mode, like the Smart switch) where the region under the pointer (entered_regionview) is ALWAYS prioritised over the selection for all region actions. The current situation seems to be analogous to a word processor where Ctrl-i italicises the current selection, but Ctrl-B emboldens the word under the mouse pointer. |
|
|
Any thoughts on a resolution for this? Is it worth me working up a patch to make this behaviour optional? |
|
|
OK, here's a patch to make this behaviour configurable. |
|
|
The analogy with a word processor isn't really fair. Both of those examples (italicize and embolden) only require knowledge of the target of the operation: which word? Split requires 2 things: the target of the operation (which region(s)?) and the location of the operation. Neither the region selection nor the mouse location alone provide all the required information. |
|
|
Sure, it's not an exact analogy, but the fact that currently the selection is ignored is the point. |
|
|
A radical thought perhaps, but isn't the idea of a persistent "selection" when Edit point=mouse actually redundant? Shouldn't "the selection" be considered to be whatever is under the mouse pointer (plus any other equivalent regions) at any particular moment? If the mouse is over the track headers, it should be a track selection: if it's over a region, it should be a region selection. I rarely use EP=mouse, possibly because it's not always clear in my mental model of it what will happen, depending on what (if anything) is selected. Having the selection explicitly and visually follow the mouse would make it absolutely clear what any editing operations were about to apply to. |
|
|
This could be a possibility, perhaps for a new edit mode (essentially what I suggested in 0007994:0021386). But this mode would not be useful for the particular case which prompted this issue, being that it is now impossible to split a region that is not the topmost. (AFAICT, the use-case for which the change was made seems to be a situation where the user should just use the Cut tool anyway.) |
|
|
Hi, sorry to bump this, but would it be OK to have some feedback on the configuration patch I offered? No-one can deny that the new behaviour makes operations difficult or time-consuming, that were previously straightforward. And this change seems to have been prompted by a single request from one user on the Mixbus forum. There are configuration options for many more specialist preferences. https://tracker.ardour.org/view.php?id=7994#c24346 |
- Anonymous
