Loop points don't follow tempo change edit

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):

_The underlying design issue is, I believe, that the selection region and the loop region are now totally independent entiti_es.


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

@r2scharf: I added a comment in that bug thread about your experience and expectations in this regard.


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:



Thank you Peter.