Bug 501 – Vertical drag in selected area of a clip gives wrong behaviour if selection extends past clip

••• Introduction •••
••• Keywords •••

Audacity 3.0.3 development began 19th April 2021

Audacity Bugzilla

Bug 501 - Vertical drag in selected area of a clip gives wrong behaviour if selection extends past clip


Summary:	Vertical drag in selected area of a clip gives wrong behaviour if selection e...

Status:	RESOLVED FIXED

Product:	Audacity
Classification:	Unclassified
Component:	Multiclip
Version:	2.0.1
Hardware:	PC All

Importance:	P3 Repeatable
Assigned To:	Paul L

URL:	http://gaclrecords.org.uk/bugs/time_s...
Keywords:

Depends on:
Blocks:
	Show dependency tree / graph

Reported:	2012-05-10 10:15 UTC by Bill Wharrie
Modified:	2018-08-20 11:51 UTC (History)
CC List:	7 users (show)

See Also:	500
Steps To Reproduce:	1) New project 2) Generate tone 3) Split it into 4 or more clips 4) Add new track 5) Fit vertical if needed 6) Make a selection across the second split line 7) With Time Shift tool, click in selected area of the third clip 8) Drag left - the clip won't move 9) Without releasing mouse button, drag down - The dragged clip moves into the bottom track; the second clip moves left covering part of the first clip; a "faint clip line" appears between clips 1 and 2 1) New Project 2) New Stereo Track 3) Generate tone 4) Split it into 4 or more clips 5) Add new stereo track - Fit vertically if needed 6) Make a selection across the second clip line 7) With the Time Shift Tool, click in the selected area of the top channel of the third clip and drag down - the left channel of the third clip and the right channel of the second clip move to the second track 8) Undo 9) With the Time Shift Tool, click in the selected area of the top channel of the third clip and drag left then down - the left channel of the third clip and the right channel of the second clip move to the second track; also, the left-channel portion of the second clip moves over onto the first clip and a faint clip line appears. 10) Undo 11) With the Time Shift Tool, click in the selected area of the lower channel of the third clip and drag down - the second clip moves down to the lower track See also comment #6
Release Note:	GROUP:Envelopes and Clips * '''A clip may now be vertically dragged from inside a selection region, but if that region extends over the edge of the clip into space or into an adjoining clip there may be unexpected behavior''': one channel of a stereo clip may jump sideways a mono clip may fail to horizontal-drag in its new track ** faint, specious clip lines could occur if the clip is dragged back to its original track. <ul style="list-style-image: none; list-style-type: none">'''Workaround:''' Edit > Undo if necessary then drag from outside the selection region or single-click in the clip to remove the selection.</ul>
First Git SHA:
Group:	---
Workaround:
Closed:	2018-08-20 00:00:00

Flags:	gale: Test‑OK‑Win+ gale: Test‑OK‑Mac+ gale: Test‑OK‑Lin+

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.

Description Bill Wharrie 2012-05-10 10:15:30 UTC

Comment 1 Gale Andrews 2012-05-12 01:44:06 UTC

These are somewhat similar behaviours to those fixed in bug 373. 

Also occurs on Linux, so noted "Platform" as "All". 

Release Note added because the bug was rated P3 or above.

Comment 2 Gale Andrews 2012-08-18 01:51:49 UTC

Also see URL http://gaclrecords.org.uk/bugs/time_shift_group.zip which demonstrates clip jumping in non-overlapping clips that have been selected over. 

*Drag from the left channel of track 3 upwards to track 2 then downwards to track 3 and release. The right channel of the track 2 clip jumps right, and the right channel of the track 3 clip jumps left. 

* Drag from the right channel of track 3 upwards to track 2 then downwards to track 3 and release. Both channels of the clip in track 2 jump down to track 3. 

* Many other permutations.

Comment 3 Paul L 2016-01-24 23:20:38 UTC

Fixed here: https://github.com/audacity/audacity/commit/d70ff3337d1587404eb2a692dc8c23cea97c9e48

Comment 4 Peter Sampson 2016-01-27 09:18:04 UTC

What I get is the whole of Clip 2 and Clip 3 moved down properly into the lower track gor both mono and stereo.

I assume that both clips move because we have a selection that straddles clip line 2 and we have a selection in both Clips 2 and 3 - but I'm no expert here (I've never been a user of clips)

But to me this looks like expected behavior on W10 audacity-win-r17c9369-2.1.3-alpha-26-jan-16

Comment 5 Paul L 2016-01-27 10:11:42 UTC

Peter, the time-shift tool behaves differently, depending whether you click inside the selection or out.  If out, then you only move the clip you clicked and its stereo partner.  If in, you move all clips that contain any part of the selection.  At least that is what I implemented.  The old behavior described herein was strange -- the stereo partner of the clicked clip was incorrectly chosen by the program, and overlapping of clips sometimes happened.

Besides the clips, there are also label tracks, which may shift all their labels left and right.  Time shift never affects only some of the labels in a track and not others.  Would that be desirable enhancement?  There was a comment in the code saying so.

Also holding Ctrl causes shift up and down only with no horizontal movement, and holding Shift causes only the clicked track to shift, and only horizontally.

(I just noticed that shift-drag does not move sync-locked tracks too.  Perhaps that should be counted as another bug.)

Comment 6 Paul L 2016-02-18 14:39:47 UTC

My fix had this unintended consequence described by Steve:

Steps to reproduce:
1) Generate a track
2) Duplicate the track
3) Zoom out a bit so there's some space at the end
4) Select the second track
5) Switch to the time shift tool
6) Drag the audio from the second track to the end of the audio in the
first track.
Step 6 can't be done without first dragging the clip along, then
release the mouse button, then drag the clip up.

Reopening until I fix that.

Comment 7 Gale Andrews 2016-09-18 20:10:56 UTC

Seems OK, I also tested it with stereo tracks (comment 2) and with Time Shift in Multi-Tool.

(In reply to Paul L from comment #6)
> My fix had this unintended consequence described by Steve: 
As this problem does not seem to be depend explicitly on selections, I started a new bug 1516 for it and resolved this one. It gives us a more accurate release note. 

(In reply to Paul L from comment #5)
> Besides the clips, there are also label tracks, which may shift all 
> their labels left and right. Time shift never affects only some of 
> the labels in a track and not others. Would that be desirable 
> enhancement? There was a comment in the code saying so.
Personally I think it would be an intuitive enhancement if you could select over labels and then drag those labels and the selection, else if no selection, drag all the labels. 

> I just noticed that shift-drag does not move sync-locked tracks too. 
> Perhaps that should be counted as another bug.
I actually don't think so, otherwise SHIFT-drag behaves the same as drag when Sync-Lock Tracks is on.  The way it is now, you can SHIFT-drag to drag all clips only in the track clicked on, whether Sync-Lock is off and other tracks selected, or whether Sync-Lock is on and other tracks Sync-Lock selected.