Selection moves when dragging a selected clip

[Bill Wharrie]

Observed on 1.3.10-alpha-Nov 1 2009 Mac

New Project
Linking off
Generate 30 sec tone
Split in half
Zoom to fit then zoom out once
Double-click to select second clip
Slowly drag second clip right with time shift tool
- problem - first clip moves with it - this shouldn't happen, should it?
Undo time shift
Quickly drag second clip right with time shift tool
- problem - selection moves to the right
Undo
Slowly drag second clip right with time shift tool, then without  
letting go, slowly drag left
- problem - selection quickly moves to start at zero
Stop drag when first clip is partially covered by the selection
Edit > Cut
- the part of the first clip covered by the selection is cut
-- so the selection really is moving. Why?

Known workarounds:
If you don't want the first clip to move with the second, just click  
anywhere with the selection tool and drag the second clip.

But ...
If you want to move two clips together with linking off you need to  
drag a selection that spans the two clips then drag with the time  
shift tool inside the selection (dragging outside the selection drags  
just one clip which is correct behaviour). In this case the selection  
will move as above.

-- Bill

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Al Dimond]

On Sunday 01 November 2009 08:03:12 Bill Wharrie wrote:

> Observed on 1.3.10-alpha-Nov 1 2009 Mac
>
> New Project
> Linking off
> Generate 30 sec tone
> Split in half
> Zoom to fit then zoom out once
> Double-click to select second clip
> Slowly drag second clip right with time shift tool
> - problem - first clip moves with it - this shouldn't happen,
>  should it? Undo time shift

I can reproduce this behavior and I agree that it's wrong.

> Quickly drag second clip right with time shift tool
> - problem - selection moves to the right

When you say "selection moves to the right", what do you mean? Does
the selection (the selected region of time as shown within the time
ruler) move relative to the second clip?  Sometimes if I drag quickly
I see the second clip move and the first stay put; other times the first
clip moves with it.  It seems to depend on where the clips have been
shifted to overall, which leads me to believe it's probably a problem
with floating point rounding.

> Undo
> Slowly drag second clip right with time shift tool, then without
> letting go, slowly drag left
> - problem - selection quickly moves to start at zero

Again, does the selection in the ruler change relative to the clips,
such that it overlaps the first clip or even more than that, or is it
that the clips move quickly to zero?  I haven't been able to reproduce
either, but I'll keep an eye out for it, and for parts of the code
that could cause it.

> Stop drag when first clip is partially covered by the selection
> Edit > Cut
> - the part of the first clip covered by the selection is cut
> -- so the selection really is moving. Why?
>
> Known workarounds:
> If you don't want the first clip to move with the second, just
>  click anywhere with the selection tool and drag the second clip.
>
> But ...
> If you want to move two clips together with linking off you need to
> drag a selection that spans the two clips then drag with the time
> shift tool inside the selection (dragging outside the selection
>  drags just one clip which is correct behaviour). In this case the
>  selection will move as above.
>
> -- Bill

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Al Dimond]

On Monday 02 November 2009 15:45:18 Al Dimond wrote:

> On Sunday 01 November 2009 08:03:12 Bill Wharrie wrote:
> > Observed on 1.3.10-alpha-Nov 1 2009 Mac
> >
> > New Project
> > Linking off
> > Generate 30 sec tone
> > Split in half
> > Zoom to fit then zoom out once
> > Double-click to select second clip
> > Slowly drag second clip right with time shift tool
> > - problem - first clip moves with it - this shouldn't happen,
> >  should it? Undo time shift
>
> I can reproduce this behavior and I agree that it's wrong.
>

This is pretty easy to fix, and I haven't seen anything obvious that
would cause the other behaviors Bill described (though I will keep an
eye out).

I have one concern specific to the time-shift tool: some of its
behavior in linked mode is inconsistent.  Say you have two wave
tracks, each selected and with a clip within the selection, and a
label track between them (so they're in different groups).  With
linking off, if you start a time-shift within the selection both clips
move.  With linking on only the track you drag in moves (along with
any other clips in its group that overlap the selection region).  
Because the selection extends into two groups, I think all clips in
both groups that overlap the selection region should move.  This isn't
a very hard change, but I want to see if there are any objections
before I go ahead with it.

Then I have a more general concern.  Changing this behavior requires
changing a test of whether a clip overlaps the selection.  Before, the
test was basically (clip0 <= t1 && clip1 >= t0); after the change it's
(clip0 < t1 && clip1 > t0).  I have checked the wiki and can't find a
standard for this.  Many places we test overlapping regions using <=
and >=, others we use < and >, sometimes we use one test on the front
end and a different one on the back.  And in WaveTrack::HandlePaste()
we only consider a clip to overlap the selection if it overlaps by at
least one sample.  We might benefit from some standardization.

 - Al

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[James Crook]

Al Dimond wrote:
> I have one concern specific to the time-shift tool: some of its
> behavior in linked mode is inconsistent.  
Maybe so, but linked mode will be off in 2.0.
My view is that this (inconsistencies in linked mode with time shift in
general) is a classic case of doing 'different things to the timelines
of different tracks in the same group'.  There is no clear criterion of
whether to move labels.

> Say you have two wave
> tracks, each selected and with a clip within the selection, and a
> label track between them (so they're in different groups).  With
> linking off, if you start a time-shift within the selection both clips
> move.  With linking on only the track you drag in moves (along with
> any other clips in its group that overlap the selection region).  
> Because the selection extends into two groups, I think all clips in
> both groups that overlap the selection region should move.  This isn't
> a very hard change, but I want to see if there are any objections
> before I go ahead with it.
>  

OK with proposal, but think it's possibly wasteful to put energy into
that coding now before we have an overall plan for linking when some
tracks selected and not others.  In other words, you might find overall
you're doing more work to get it working than needed.

> Then I have a more general concern.  Changing this behavior requires
> changing a test of whether a clip overlaps the selection.  Before, the
> test was basically (clip0 <= t1 && clip1 >= t0); after the change it's
> (clip0 < t1 && clip1 > t0).  I have checked the wiki and can't find a
> standard for this.  Many places we test overlapping regions using <=
> and >=, others we use < and >, sometimes we use one test on the front
> end and a different one on the back.  And in WaveTrack::HandlePaste()
> we only consider a clip to overlap the selection if it overlaps by at
> least one sample.  We might benefit from some standardization.
>  

How about a function to test if a selection and a clip/label overlap?

--James.



------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel