Silding Stretch and Set Rate do not affect Sync-Locked tracks

[petersampsonaudacity]

Bug description

Sync-Locked Tracks are not affected by all actions that change the length of a track in the Sync-Locked Track Group. Applying Paulstretch (@Paul-Licameli: that one has been fixed) or Sliding Stretch or using the Audio Track dropdown menu to change sample rate will leave the other Sync-Locked tracks desynchronized.

Originally logged on Bugzilla as P3 838 in 2015
https://bugzilla.audacityteam.org/show_bug.cgi?id=838

Steps to reproduce

1. Have a clip on a mono track
2. Have a clip on a stereo track
3. Have a label track with a label past the zero time mark
4. Enabel Tracks > Sync Lock tracks
5. Select a portion of the stereo clip and apply Paulstretch or Sliding Stretch (e.g. -50/-50) or change the track's rate using TCP (see the screenshot)
6. Observe

Expected behavior

Sync-locked tracks should be affected by Paulstretch, Sliding Stretch and Set Rate

Actual behavior

Only the stereo track's clip has been stretched; no changes have been made to either mono or label track:

Screenshots

Additional information (please complete the following information):

• OS: all OS
• Version: originally reported in Audacity 2.1.0 = but still exists in 3.3.3

Additional context

We should really be fixing this as it is a gross inconsistency - and defeats the objective of having a Sync-Locked Track Group

[Paul-Licameli]

@Paul-Licameli @LWinterberg Note that sync lock adjustment only inserts silence when another track lenghtens, or delete from a track when the other shortens. Sync lock can affect label tracks and note tracks.

SetRate is unlike effects, in that it can only affect an entire track, not a selection.

It might make more sense to apply time stretching to the other non-wave tracks, when they are not wave tracks. But I think it is agreed to leave that out of the scope of this release.

The Sliding Stretch effect is unlike anything else, in applying a non-uniform time stretch. If we were to apply time stretching to other kinds of tracks, the time remapping would not be a simple linear one.

[Paul-Licameli]

PaulStretch was already fixed as noted. Sliding stretch is also fixed.

Whether sync lock really should be applied in case of change of rate -- is that debatable? @LWinterberg

[chinakov]

Tested PaulStretch and Sliding Stretch, it now works as intended.
Waiting on the verification of change of rate question - @LWinterberg

[Paul-Licameli]

It was not hard to implement sync lock for change of rate, so I did it anyway

[chinakov]

Alright, tested. Change or rate also works. Thanks!