When changing tempo of loops in 3.1.3, why do the former loop points remain, as opposed to automatically changing & looping to the new, edited tempo change?
I don’t want to know about these old, loop points when I just changed the tempo and want (need!) to hear the new version, so adding the Shift-L step to make the new edit loop is counter-productive.
Can somebody explain to me how this is a good thing?
Mac Mini 2018 (Intel)
OS Monterey 12.2.1
3 GHz 6-Core Intel Core i5
32 GB 2400 MHz DDR4
That would have been a design decision by the development team.
When changing tempo, the selected region changes size. To adjust the loop region to match the updated selection size, right click on the Timeline (the ruler at the top), and select “Set loop to selection”.
There is a simple workaround.
After you have applied the Change Temp (or any effect that changes the length of the selection) the selection length is changed appropriately.
So then just use Transport > Looping > Set Loop to Selection - or its shortcut Shift + L.
If you feel strongly that the design decision not to change the Loop region automatically in this use case then you could raise an enhancement request on GitHub (You will need to register - but it is free to do so):
https://github.com/audacity/audacity/issues
_The underlying design issue is, I believe, that the selection region and the loop region are now totally independent entiti_es.
Peter.
Testing that workaround made me discover what I think is a bug that I have just logged on GitHub:
Transport > Looping > Set Loop to Selection does not appear to be put on the undo stack. #2625
https://github.com/audacity/audacity/issues/2625
@r2scharf: I added a comment in that bug thread about your experience and expectations in this regard.
Peter.
Steve wrote:
That would have been a design decision by the development team…
And not a good one IMO.
When one selects a region of audio and applies an effect to it, what ever it may be, the effect is applied
to the region and it updates accordingly.
So why should changing tempo or speed not update that as well?
It seems odd.
For example, the user may have spent some time to accurately select an exact region that they may want to slow down or speed up.
It makes sense that the selection will update once it’s changed instead of the user now having to know just how much it has
shrunk or grown then have to re-select the region if subsequent effects need to be applied.
Earlier versions of Audacity (at least in the 2.X series), do it properly and it makes sense to maintain it.
Every other DAW/Audio Editor I have used, also update the selection if it’s duration changes.
This of course also includes any loop points.
@Paul2 - I added your comments to the bug thread on GitHub:
https://github.com/audacity/audacity/issues/2625
Peter.
Thank you Peter.
As the one who started this thread, and still experiencing this ongoing issue many times since, I thought I’d check back to see if there’s been any progress on getting this suggestion implemented or even discussed more than it’s been.
Here’s two screenshots of what I’m experiencing:
This is my issue. I just want the loop points to automatically follow the edits I make so I I don’t have to do the “shift-L” move every time I make a tempo (or other) change. Am I “nit-picking” here? Maybe, but if you’re doing thousands of edits, this extra move adds up, seems unnecessary, and is ultimately more time-consuming.
If this isn’t able to be changed/corrected, I’m curious as to why the developers feel this move should remain independent once an edit is done?
I’ve run into a head-scratcher while working on my Mac Mini (2018) running macOS Monterey 12.2.1. I often create music loops in Audacity, and I’ve noticed that when I change the tempo of these loops in version 3.1.3, the original loop points remain in place, and the loop doesn’t automatically adapt to the new tempo. This can be quite cumbersome because I just want to hear the new version right away without having to go through the extra step of adjusting the loop points manually using Shift-L.
We’re doing some major improvements to how tempo works for Audacity 3.4 and in subsequent patches. This should get fixed soon.
