Occasionally, <1> and <3> cause selection to end of track instead of actually zooming in/out.
I am still not sure of the circumstances that lead to this. Any ideas?
This is really annoying because sometimes I have a particular endpoint selected but then it gets lost.
I can’t reproduce this on w10 with either 2.2.1 or the alpha for the upcoming 2.2.2
If you have a particular point of interest why not drop a (temporary) label there. Ctrl+B will label the current cursor position.
Okay thanks for the reply. Well, the problem only occurs about 10-20% of the time. Still have not figured out the actions that trigger it.
I could try the bookmark technique.
Probably the most common thing I use Audacity for is splits, crops, moves and fade-ins/outs for a single spoken-word track of a weekly podcast. This scenario is “busy-work” that I try to do quickly. I ideally only spend a few seconds at each point and then move onward. After export, I delete the track (this is an “assembly-line” Project that I have stored). Regarding the clip moves, I likely would not want to snap to any of those bookmarks – they would be disposable items. I wonder about workflow. …how much time it would take to add a bookmark before doing each split and crop vs simply doing a normal workflow with “surprises”.
Thanks again! I think I will keep doing a normal workflow, in hopes of uncovering what triggers the issue.
For the upcoming 2.2.2 ine of the developers has recently been making some changes to zooming to try to make it a bit more user-friendly:
Zooming with the mouse wheel
We have changed mouse wheel zooming so that the focus for the zoom is:
The leftmost or rightmost edge of the current selection, or the editing cursor position (if any of these exist).
Otherwise zoom focus is as it was before, and is taken as the mouse pointer position.
Mouse position will also be used as the zoom focus if the mouse position is inside the current selection.
Okay thanks for the heads-up!