Problem with Time Shift tool when zoomed in

20 messages

Problem with Time Shift tool when zoomed in

Reply Threaded

In certain situations when using the Time Shift tool, the mouse pointer
becomes detached from the audio clip that is being moved.

To reproduce the issue:

1) Open Audacity and add a new track.
2) Zoom out so that you can see about 15 minutes on the time line.
3) Click near the 10 minute mark on the empty track and generate 1
second of a tone.
4) Zoom in on the tone so that it occupies 1/4 of the visible track.
5) Press F5 to select the Time Shift Tool
6) Click on the audio clip and drag to the left - the audio clip moves
slower than the mouse pointer and the two become separated.
7) Without releasing the left mouse button - push the audio clip to the
right - the audio clip now disappears off screen (exit stage left).

It may be worth looking at the P3 "Cursor jumps to start of scroll after
playback cursor goes past scroll" at the same time as this issue, unless
they are completely unrelated.

Steve D

------------------------------------------------------------------------------
Come build with us! The BlackBerry® 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/devconf
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Al Dimond

Re: Problem with Time Shift tool when zoomed in

Reply Threaded

On Sunday 04 October 2009 09:13:59 Steve wrote:

> In certain situations when using the Time Shift tool, the mouse pointer
> becomes detached from the audio clip that is being moved.
>
> To reproduce the issue:
>
> 1) Open Audacity and add a new track.
> 2) Zoom out so that you can see about 15 minutes on the time line.
> 3) Click near the 10 minute mark on the empty track and generate 1
> second of a tone.
> 4) Zoom in on the tone so that it occupies 1/4 of the visible track.
> 5) Press F5 to select the Time Shift Tool
> 6) Click on the audio clip and drag to the left - the audio clip moves
> slower than the mouse pointer and the two become separated.
> 7) Without releasing the left mouse button - push the audio clip to the
> right - the audio clip now disappears off screen (exit stage left).
>

Yeah, I'm seeing this. At first it appeared that the viewing window was
scrolling as I dragged left (which is sort of true; the timeline moves). The
audio clip moves relative to the timeline the same amount that the mouse moves
relative to the screen. But it's not really that it's scrolling, it's that
the timeline is shrinking. If the clip goes from 10:00 to 10:01, the timeline
when you're zoomed in only goes out to about 10:02. As the clip is dragged
left, say, to 9:58-9:59, the timeline will only extend to about 10:00, so the
viewing window has to shift left. At least this is what I gather without
looking at any code at all.

(When I'm talking about the "timeline" here I'm not really talking about
anything but the amount of ruler that can be scrolled to at a given zoom level
-- as noted, this varies considerably at different zoom levels. I don't know
how the code for this works yet.)

As a result, if you zoom back out and add a short clip at 15:00, you can see
this behavior on the clip at 15:00 but not on the clip at 10:00, since it's no
longer the last clip in the timeline.

Clearly the current behavior is not correct. But I think we have to allow the
right edge of the timeline to move left as the last clip does. Would you
consider it correct for the clip to move with the mouse as the timeline
shrinks? My concern with this is that a user could drag the clip to the left
edge of the screen and back and it would wind up in a different place in time
(and the original location would probably be unavailable). Would it be better
for the timeline not to shrink until a later time? At the completion of the
time-shift might be weird, because then the whole display would snap-move
right at the end of dragging. We could have the end of the timeline not
change until it's scrolled off the screen (or a zoom action is performed); this
might disrupt people dragging the scroll bar a little bit (unless we also
didn't allow the shrink to happen while the scroll bar was held down).

I can't look at the code right now; I think the last option would be the
friendliest. Let the extra space remain viewable until it's been scrolled off
the screen and the scrollbar isn't held down. But I'm not sure whether that's
hard to do or not.

> It may be worth looking at the P3 "Cursor jumps to start of scroll after
> playback cursor goes past scroll" at the same time as this issue, unless
> they are completely unrelated.
>

I hadn't noticed this P3 before; it doesn't sound like they would be related
in code, but you never know. It seems to really bother a few people. Maybe
I'll take a look at that as well, since I think all the P2s are either taken,
Windows-only, or things I can't repro.

- a"w"d

------------------------------------------------------------------------------
Come build with us! The BlackBerry® 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/devconf
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Gale (Audacity Team)

Re: Problem with Time Shift tool when zoomed in

Reply Threaded

In reply to this post by Stevethefiddle

| From Steve <[hidden email]>
| Sun, 04 Oct 2009 16:13:59 +0100
| Subject: [Audacity-devel] Problem with Time Shift tool when zoomed in

In 7) I seem able to drag the clip back from off-screen (from the
right).

I tried a 3 minute track fitted to project, selected 1 second
using Selection Toolbar, split the selection, dragged
the surrounding audio well away, then zoomed in on the
selection of one second, so it occupied a quarter of the screen
surrounded by white space. Although that scenario appeared
visually like yours, the clip dragged properly for me.

So it looks to me like no more than a nuisance issue really
(predictable, and workaround is to zoom out a bit so you
can drag the clip to where you really want to)?

I'd say it's less bad than the unpredictable behaviour
when trying to drag clips apart with Time Shift Tool
(you never really know how many attempts that is going
to take). That is only a P4 at the moment, attached to
"Selection bugs when zoomed in" because it seems
exactly where you click may determine if you are going
to be able to drag or not.

> It may be worth looking at the P3 "Cursor jumps to start of scroll after
> playback cursor goes past scroll" at the same time as this issue, unless
> they are completely unrelated.

It would not have struck me they were related. You don't
have to zoom in far (from any starting position) to replicate
that one.

Thanks

Gale

------------------------------------------------------------------------------
Come build with us! The BlackBerry® 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/devconf
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Stevethefiddle

Re: Problem with Time Shift tool when zoomed in

Reply Threaded

On Sun, 2009-10-04 at 18:47 +0100, Gale Andrews wrote:

> | From Steve <[hidden email]>
> | Sun, 04 Oct 2009 16:13:59 +0100
> | Subject: [Audacity-devel] Problem with Time Shift tool when zoomed in
> > In certain situations when using the Time Shift tool, the mouse pointer
> > becomes detached from the audio clip that is being moved.
> >
> > To reproduce the issue:
> >
> > 1) Open Audacity and add a new track.
> > 2) Zoom out so that you can see about 15 minutes on the time line.
> > 3) Click near the 10 minute mark on the empty track and generate 1
> > second of a tone.
> > 4) Zoom in on the tone so that it occupies 1/4 of the visible track.
> > 5) Press F5 to select the Time Shift Tool
> > 6) Click on the audio clip and drag to the left - the audio clip moves
> > slower than the mouse pointer and the two become separated.
> > 7) Without releasing the left mouse button - push the audio clip to the
> > right - the audio clip now disappears off screen (exit stage left).
>
> In 7) I seem able to drag the clip back from off-screen (from the
> right).
>
> I tried a 3 minute track fitted to project, selected 1 second
> using Selection Toolbar, split the selection, dragged
> the surrounding audio well away, then zoomed in on the
> selection of one second, so it occupied a quarter of the screen
> surrounded by white space. Although that scenario appeared
> visually like yours, the clip dragged properly for me.

Perhaps it's just a Linux thing, though it does the same when running
the Windows version in Wine.

*** Update ***
OK, tested in real Windows (well XP in VirtualBox) and it does not have
this problem.
***

There's also a weird scrolling effect of the time-line (see post by Al
Dimond), which on my machine appears to be real scrolling rather than
shrinking of the time line. Anyhow, it's quite disorientating and
clearly not what is supposed to happen.

> So it looks to me like no more than a nuisance issue really
> (predictable, and workaround is to zoom out a bit so you
> can drag the clip to where you really want to)?

I noticed this effect while investigating a question about moving small
clips within a much longer project. The user had previously been on
Audacity 1.2.6 where a track could be dragged by clicking anywhere on
the track (including white-space) and was now having difficulty clicking
on a tiny audio clip. The obvious answer is to zoom in so that the audio
clip is large enough to clearly see and click on. However, if zooming in
pushes the start of the time line off screen, then the clip does not
move to where the mouse moves.

I tried doing some fancy mouse moves - clicking and dragging while
zooming with Ctrl+wheel, but when the pointer and the clip part company
it is just impossible. (same when clicking then pressing Ctrl+1/2/3)

> I'd say it's less bad than the unpredictable behaviour
> when trying to drag clips apart with Time Shift Tool
> (you never really know how many attempts that is going
> to take). That is only a P4 at the moment, attached to
> "Selection bugs when zoomed in" because it seems
> exactly where you click may determine if you are going
> to be able to drag or not.

Oh yes, that is certainly an annoying issue when a project involves a
lot of cutting and dragging, but at least there is an easy workaround of
re-selecting the clip before moving it.

The workaround for this time shift tool problem would be to zoom in,
select and cut the clip, zoom out, zoom into the new location and paste,
but even then, any fine adjustment of the position is very tricky
because the clip does not move at the same rate as the mouse.

>
> > It may be worth looking at the P3 "Cursor jumps to start of scroll after
> > playback cursor goes past scroll" at the same time as this issue, unless
> > they are completely unrelated.
>
> It would not have struck me they were related. You don't
> have to zoom in far (from any starting position) to replicate
> that one.

They may well not be - not knowing the code I've no idea, but thought it
worth mentioning just in case.

Steve D

> Thanks
>
>
> Gale

------------------------------------------------------------------------------
Come build with us! The BlackBerry® 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/devconf
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Bill Wharrie

Re: Problem with Time Shift tool when zoomed in

Reply Threaded

In reply to this post by Stevethefiddle

I can confirm this on Mac (G5, 10.5.8, Audacity 1.3.9)

The effect goes away if you zoom out far enough, and seems to be
related to the fact that the timeline is scrolling while you are
dragging - i.e. the separation of the pointer and the clip does not
happen if the timeline is not actively scrolling while you drag. The
selection indicator in the timeline can get out of sync with the
selection in the track as well, in the zoomed-in case.

-- Bill

On 4-Oct-09, at 11:13 AM, Steve wrote:

> In certain situations when using the Time Shift tool, the mouse
> pointer
> becomes detached from the audio clip that is being moved.
>
> To reproduce the issue:
>
> 1) Open Audacity and add a new track.
> 2) Zoom out so that you can see about 15 minutes on the time line.
> 3) Click near the 10 minute mark on the empty track and generate 1
> second of a tone.
> 4) Zoom in on the tone so that it occupies 1/4 of the visible track.
> 5) Press F5 to select the Time Shift Tool
> 6) Click on the audio clip and drag to the left - the audio clip moves
> slower than the mouse pointer and the two become separated.
> 7) Without releasing the left mouse button - push the audio clip to
> the
> right - the audio clip now disappears off screen (exit stage left).
>
> It may be worth looking at the P3 "Cursor jumps to start of scroll
> after
> playback cursor goes past scroll" at the same time as this issue,
> unless
> they are completely unrelated.
>
> Steve D
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry® 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/devconf
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel

------------------------------------------------------------------------------
Come build with us! The BlackBerry® 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/devconf
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Gale (Audacity Team)

Re: Problem with Time Shift tool when zoomed in

Reply Threaded

In reply to this post by Al Dimond

| From Al Dimond <[hidden email]>
| Sun, 4 Oct 2009 11:44:13 -0600
| Subject: [Audacity-devel] Problem with Time Shift tool when zoomed in

> On Sunday 04 October 2009 09:13:59 Steve wrote:
> > In certain situations when using the Time Shift tool, the mouse pointer
> > becomes detached from the audio clip that is being moved.
> >
> > To reproduce the issue:
> >
> > 1) Open Audacity and add a new track.
> > 2) Zoom out so that you can see about 15 minutes on the time line.
> > 3) Click near the 10 minute mark on the empty track and generate 1
> > second of a tone.
> > 4) Zoom in on the tone so that it occupies 1/4 of the visible track.
> > 5) Press F5 to select the Time Shift Tool
> > 6) Click on the audio clip and drag to the left - the audio clip moves
> > slower than the mouse pointer and the two become separated.
> > 7) Without releasing the left mouse button - push the audio clip to the
> > right - the audio clip now disappears off screen (exit stage left).
> >
>
> Yeah, I'm seeing this. At first it appeared that the viewing window was
> scrolling as I dragged left (which is sort of true; the timeline moves). The
> audio clip moves relative to the timeline the same amount that the mouse moves
> relative to the screen. But it's not really that it's scrolling, it's that
> the timeline is shrinking. If the clip goes from 10:00 to 10:01, the timeline
> when you're zoomed in only goes out to about 10:02. As the clip is dragged
> left, say, to 9:58-9:59, the timeline will only extend to about 10:00, so the
> viewing window has to shift left. At least this is what I gather without
> looking at any code at all.
>
> (When I'm talking about the "timeline" here I'm not really talking about
> anything but the amount of ruler that can be scrolled to at a given zoom level
> -- as noted, this varies considerably at different zoom levels. I don't know
> how the code for this works yet.)
>
> As a result, if you zoom back out and add a short clip at 15:00, you can see
> this behavior on the clip at 15:00 but not on the clip at 10:00, since it's no
> longer the last clip in the timeline.
>
> Clearly the current behavior is not correct. But I think we have to allow the
> right edge of the timeline to move left as the last clip does. Would you
> consider it correct for the clip to move with the mouse as the timeline
> shrinks? My concern with this is that a user could drag the clip to the left
> edge of the screen and back and it would wind up in a different place in time
> (and the original location would probably be unavailable). Would it be better
> for the timeline not to shrink until a later time? At the completion of the
> time-shift might be weird, because then the whole display would snap-move
> right at the end of dragging. We could have the end of the timeline not
> change until it's scrolled off the screen (or a zoom action is performed); this
> might disrupt people dragging the scroll bar a little bit (unless we also
> didn't allow the shrink to happen while the scroll bar was held down).
>
> I can't look at the code right now; I think the last option would be the
> friendliest. Let the extra space remain viewable until it's been scrolled off
> the screen and the scrollbar isn't held down. But I'm not sure whether that's
> hard to do or not.

Hi Al

I'm probably being "thick" but I'm not really following your argument.
Is the timeline "shrinking" when it moves? It isn't for me on Windows
XP. If I start with 10 seconds visible I still get 10 seconds visible
while the mouse progressively detaches from the clip.

Why does the timeline have to move left with the last clip, but not with
others? That isn't consistent behaviour. One thing that is consistent
with any clips is that when you drag it left or right you can't take
it any farther when it reaches the end of the scroll. This may be a
longer term decision, but would it be better if a scroll was initiated
when the end was reached, to save the extra step of zooming out
or using the horizontal scroll bar to complete the drag? Or I
suppose you could always scroll when dragging, even within the
scroll width, but I would feel a bit disorientated by that.

> > It may be worth looking at the P3 "Cursor jumps to start of scroll after
> > playback cursor goes past scroll" at the same time as this issue, unless
> > they are completely unrelated.
> >
>
> I hadn't noticed this P3 before; it doesn't sound like they would be related
> in code, but you never know. It seems to really bother a few people. Maybe
> I'll take a look at that as well, since I think all the P2s are either taken,
> Windows-only, or things I can't repro.

I'd be pleased of course if a fix was safe. "Zoom to selection
being 90%" suggested by James would be good anyway and
suggested by others, but no fix for this (I may not want to
draw a selection).

Note that there a number of votes for a "Feature Request"
that playback scrolls continually when you play (the cursor
stops put, but the timeline moves).

Gale

------------------------------------------------------------------------------
Come build with us! The BlackBerry® 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/devconf
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Bill Wharrie

Re: Problem with Time Shift tool when zoomed in

Reply Threaded

In reply to this post by Al Dimond

OK, now I see what you're saying. If it is the only clip, or the last
clip, in the track, then Audacity is constantly redefining what the
"right edge of the track" is as you drag the clip left. At these
extreme zoom levels it *looks* like the track is scrolling (timeline
changes), but really what is happening is the right edge is constantly
changing. The question is, why does the timeline need to shrink at
all? Is Audacity somewhere keeping track of the length of the longest
track to facilitate zoom-to-fit? If you waited until the drag was
finished and then updated this calculation would that cause the
display to jump?

Similarly you can defeat this (wrong) effect by creating a 10-minute
track filled with tone then create a second track with 1 second of
tone at the 5-minute mark. Since Audacity thinks that the timeline
should be a minimum of 10 minutes long no shrinking occurs when you
drag the 1-second clip in the second track.

Given that this effect occurs only when dragging the last clip in the
longest track, does this rate a P2?

-- Bill

On 4-Oct-09, at 1:44 PM, Al Dimond wrote:

> On Sunday 04 October 2009 09:13:59 Steve wrote:
>> In certain situations when using the Time Shift tool, the mouse
>> pointer
>> becomes detached from the audio clip that is being moved.
>>
>> To reproduce the issue:
>>
>> 1) Open Audacity and add a new track.
>> 2) Zoom out so that you can see about 15 minutes on the time line.
>> 3) Click near the 10 minute mark on the empty track and generate 1
>> second of a tone.
>> 4) Zoom in on the tone so that it occupies 1/4 of the visible track.
>> 5) Press F5 to select the Time Shift Tool
>> 6) Click on the audio clip and drag to the left - the audio clip
>> moves
>> slower than the mouse pointer and the two become separated.
>> 7) Without releasing the left mouse button - push the audio clip to
>> the
>> right - the audio clip now disappears off screen (exit stage left).
>>
>
> Yeah, I'm seeing this. At first it appeared that the viewing window
> was
> scrolling as I dragged left (which is sort of true; the timeline
> moves). The
> audio clip moves relative to the timeline the same amount that the
> mouse moves
> relative to the screen. But it's not really that it's scrolling,
> it's that
> the timeline is shrinking. If the clip goes from 10:00 to 10:01,
> the timeline
> when you're zoomed in only goes out to about 10:02. As the clip is
> dragged
> left, say, to 9:58-9:59, the timeline will only extend to about
> 10:00, so the
> viewing window has to shift left. At least this is what I gather
> without
> looking at any code at all.
>
> (When I'm talking about the "timeline" here I'm not really talking
> about
> anything but the amount of ruler that can be scrolled to at a given
> zoom level
> -- as noted, this varies considerably at different zoom levels. I
> don't know
> how the code for this works yet.)
>
> As a result, if you zoom back out and add a short clip at 15:00, you
> can see
> this behavior on the clip at 15:00 but not on the clip at 10:00,
> since it's no
> longer the last clip in the timeline.
>
> Clearly the current behavior is not correct. But I think we have to
> allow the
> right edge of the timeline to move left as the last clip does.
> Would you
> consider it correct for the clip to move with the mouse as the
> timeline
> shrinks? My concern with this is that a user could drag the clip to
> the left
> edge of the screen and back and it would wind up in a different
> place in time
> (and the original location would probably be unavailable). Would it
> be better
> for the timeline not to shrink until a later time? At the
> completion of the
> time-shift might be weird, because then the whole display would snap-
> move
> right at the end of dragging. We could have the end of the timeline
> not
> change until it's scrolled off the screen (or a zoom action is
> performed); this
> might disrupt people dragging the scroll bar a little bit (unless we
> also
> didn't allow the shrink to happen while the scroll bar was held down).
>
> I can't look at the code right now; I think the last option would be
> the
> friendliest. Let the extra space remain viewable until it's been
> scrolled off
> the screen and the scrollbar isn't held down. But I'm not sure
> whether that's
> hard to do or not.
>
>> It may be worth looking at the P3 "Cursor jumps to start of scroll
>> after
>> playback cursor goes past scroll" at the same time as this issue,
>> unless
>> they are completely unrelated.
>>
>
> I hadn't noticed this P3 before; it doesn't sound like they would be
> related
> in code, but you never know. It seems to really bother a few
> people. Maybe
> I'll take a look at that as well, since I think all the P2s are
> either taken,
> Windows-only, or things I can't repro.
>
> - a"w"d
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry® 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/devconf
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel

Gale (Audacity Team)

Re: Problem with Time Shift tool when zoomed in

Reply Threaded

In reply to this post by Stevethefiddle

| From Steve <[hidden email]>
| Sun, 04 Oct 2009 21:06:34 +0100
| Subject: [Audacity-devel] Problem with Time Shift tool when zoomed in

> On Sun, 2009-10-04 at 18:47 +0100, Gale Andrews wrote:
> > | From Steve <[hidden email]>
> > | Sun, 04 Oct 2009 16:13:59 +0100
> > | Subject: [Audacity-devel] Problem with Time Shift tool when zoomed in
> > > In certain situations when using the Time Shift tool, the mouse pointer
> > > becomes detached from the audio clip that is being moved.
> > >
> > > To reproduce the issue:
> > >
> > > 1) Open Audacity and add a new track.
> > > 2) Zoom out so that you can see about 15 minutes on the time line.
> > > 3) Click near the 10 minute mark on the empty track and generate 1
> > > second of a tone.
> > > 4) Zoom in on the tone so that it occupies 1/4 of the visible track.
> > > 5) Press F5 to select the Time Shift Tool
> > > 6) Click on the audio clip and drag to the left - the audio clip moves
> > > slower than the mouse pointer and the two become separated.
> > > 7) Without releasing the left mouse button - push the audio clip to the
> > > right - the audio clip now disappears off screen (exit stage left).
> >
> > In 7) I seem able to drag the clip back from off-screen (from the
> > right).
> >
> > I tried a 3 minute track fitted to project, selected 1 second
> > using Selection Toolbar, split the selection, dragged
> > the surrounding audio well away, then zoomed in on the
> > selection of one second, so it occupied a quarter of the screen
> > surrounded by white space. Although that scenario appeared
> > visually like yours, the clip dragged properly for me.
>
> Perhaps it's just a Linux thing, though it does the same when running
> the Windows version in Wine.
>
> *** Update ***
> OK, tested in real Windows (well XP in VirtualBox) and it does not have
> this problem.
> ***

I can definitely reproduce your 1) to 6) on native Windows XP.

> There's also a weird scrolling effect of the time-line (see post by Al
> Dimond), which on my machine appears to be real scrolling rather than
> shrinking of the time line. Anyhow, it's quite disorientating and
> clearly not what is supposed to happen.

Yes on native Windows XP I seem to see scrolling but no
shrinking, as per my other post to Al in this thread.

> > So it looks to me like no more than a nuisance issue really
> > (predictable, and workaround is to zoom out a bit so you
> > can drag the clip to where you really want to)?
>
> I noticed this effect while investigating a question about moving small
> clips within a much longer project. The user had previously been on
> Audacity 1.2.6 where a track could be dragged by clicking anywhere on
> the track (including white-space) and was now having difficulty clicking
> on a tiny audio clip. The obvious answer is to zoom in so that the audio
> clip is large enough to clearly see and click on. However, if zooming in
> pushes the start of the time line off screen, then the clip does not
> move to where the mouse moves.

I was going to say those zooming in steps shouldn't be
necessary if some part of the clip is inside the time shift
icon, but perhaps it isn't obvious what should happen if
two clips were inside the icon. Maybe nothing, you have
to zoom in enough so that only one clip is somewhere
inside the icon?

The trick to drag a (single) clip of lesser width than the icon
seems to be to place the icon so it's centered across the clip.
But this very much depends on exactly where you place the
icon. If there are two clips inside the icon it seems even more
of a lottery what will happen if you drag over them.

There is an identical issue when dragging the edge of any
clip of whatever length (even if it already has white space
either side). If you lazily drag with part of the time shift
icon outside the clip edge, there is no guarantee it will drag,
though sometimes it will.

> > I'd say it's less bad than the unpredictable behaviour
> > when trying to drag clips apart with Time Shift Tool
> > (you never really know how many attempts that is going
> > to take). That is only a P4 at the moment, attached to
> > "Selection bugs when zoomed in" because it seems
> > exactly where you click may determine if you are going
> > to be able to drag or not.
>
> Oh yes, that is certainly an annoying issue when a project involves a
> lot of cutting and dragging, but at least there is an easy workaround of
> re-selecting the clip before moving it.

Does that work if the clip you want to drag away is attached to
the right edge of the other clip? The only way I know to reliably
drag the right-hand clip away is to drag the left-hand one away
first.

Gale

------------------------------------------------------------------------------
Come build with us! The BlackBerry® 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/devconf
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Stevethefiddle

Re: Problem with Time Shift tool when zoomed in

Reply Threaded

On Sun, 2009-10-04 at 23:34 +0100, Gale Andrews wrote:

> > > I'd say it's less bad than the unpredictable behaviour
> > > when trying to drag clips apart with Time Shift Tool
> > > (you never really know how many attempts that is going
> > > to take). That is only a P4 at the moment, attached to
> > > "Selection bugs when zoomed in" because it seems
> > > exactly where you click may determine if you are going
> > > to be able to drag or not.
> >
> > Oh yes, that is certainly an annoying issue when a project involves
> a
> > lot of cutting and dragging, but at least there is an easy
> workaround of
> > re-selecting the clip before moving it.
>
> Does that work if the clip you want to drag away is attached to
> the right edge of the other clip? The only way I know to reliably
> drag the right-hand clip away is to drag the left-hand one away
> first.
>
>
>
>
> Gale

I should have said DE-select the clip before moving it.
If you've just split a track then you will already have either the
Selection tool or the Multi tool, so just click anywhere on the track
before switching to the Time Shift tool then whichever bit you click on
is the bit that moves.

Steve

------------------------------------------------------------------------------
Come build with us! The BlackBerry® 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/devconf
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Al Dimond

Re: Problem with Time Shift tool when zoomed in

Reply Threaded

In reply to this post by Gale (Audacity Team)

On Sunday 04 October 2009 15:46:21 Gale Andrews wrote:
> Hi Al
>
> I'm probably being "thick" but I'm not really following your argument.
> Is the timeline "shrinking" when it moves? It isn't for me on Windows
> XP. If I start with 10 seconds visible I still get 10 seconds visible
> while the mouse progressively detaches from the clip.
>

What I'm saying is that before starting to time shift the latest point in time
that you can scroll to is 10:02.00 (around a second after the end of the
clip). After time-shifting the clip 2 seconds back, the latest point in time
that you can scroll to is 10:00.00 (again, around a second after the end of
the clip). At different zoom levels the amount of time may vary. As far as I
can tell (I haven't looked at the code yet) the fact that this "end of
timeline" point is constantly moving back forces a backwards scroll that the
time-shifting code doesn't account for.

Ultimately this "end of timeline" point has to move; if you time-shift the
last clip all the way from 10 minutes to 9 minutes (this is hard to imagine
the way the tool currently works, but if your suggested change below were
implemented it would be easy), you want the scroll bars to reflect the fact
that you have a 9-minute long project, not a 10-minute long one. But the
change should not occur while dragging around a clip with the time-shift tool.
Maybe it should take effect right after the time-shift, or maybe the extra
space remain possible-to-scroll-to until it's scrolled off-screen.

> Why does the timeline have to move left with the last clip, but not with
> others? That isn't consistent behaviour. One thing that is consistent
> with any clips is that when you drag it left or right you can't take
> it any farther when it reaches the end of the scroll. This may be a
> longer term decision, but would it be better if a scroll was initiated
> when the end was reached, to save the extra step of zooming out
> or using the horizontal scroll bar to complete the drag? Or I
> suppose you could always scroll when dragging, even within the
> scroll width, but I would feel a bit disorientated by that.
>

I agree with this. Auto-scroll behavior in the time-shift tool ought to work
just like it does in the selection tool. I think this is more of a feature
request than a bug, though.

I'm going to dive into this either later this evening or tomorrow morning
(have some other stuff to get done before that).

- a"w"d

------------------------------------------------------------------------------
Come build with us! The BlackBerry® 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/devconf
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Gale (Audacity Team)

Re: Problem with Time Shift tool when zoomed in

Reply Threaded

In reply to this post by Bill Wharrie

| From Bill Wharrie <[hidden email]>
| Sun, 4 Oct 2009 18:18:18 -0400
| Subject: [Audacity-devel] Problem with Time Shift tool when zoomed in

> OK, now I see what you're saying. If it is the only clip, or the last
> clip, in the track, then Audacity is constantly redefining what the
> "right edge of the track" is as you drag the clip left. At these
> extreme zoom levels it *looks* like the track is scrolling (timeline
> changes), but really what is happening is the right edge is constantly
> changing. The question is, why does the timeline need to shrink at
> all? Is Audacity somewhere keeping track of the length of the longest
> track to facilitate zoom-to-fit? If you waited until the drag was
> finished and then updated this calculation would that cause the
> display to jump?
>
> Similarly you can defeat this (wrong) effect by creating a 10-minute
> track filled with tone then create a second track with 1 second of
> tone at the 5-minute mark. Since Audacity thinks that the timeline
> should be a minimum of 10 minutes long no shrinking occurs when you
> drag the 1-second clip in the second track.
>
> Given that this effect occurs only when dragging the last clip in the
> longest track, does this rate a P2?

I haven't yet managed to get the timeline to display less length of time
after drag here, and I call it that the timeline is scrolling, given if
the cursor is by the selection when the scrolling starts, it will then
disappear off-right while you are left-dragging the clip. As well as
the scrolling, there can be a disconcerting change in the values
presented on the timeline as you scroll (the timeline position you
were aiming to align with no longer has an actual value attached to it).

My 2p is that it's a P3 only. Would you often get in a position where
you had zoomed in, so that you only had a short clip with a lot of
white space around it, then wanted to time shift it a long way?
If you did, it would be pretty tedious to drag it with the current
"locking" of the clip after you reach the scroll.

That doesn't stop anyone fixing it, but how sure are we that fixing
it won't make something else even worse?

Gale

> On 4-Oct-09, at 1:44 PM, Al Dimond wrote:
>
> > On Sunday 04 October 2009 09:13:59 Steve wrote:
> >> In certain situations when using the Time Shift tool, the mouse
> >> pointer
> >> becomes detached from the audio clip that is being moved.
> >>
> >> To reproduce the issue:
> >>
> >> 1) Open Audacity and add a new track.
> >> 2) Zoom out so that you can see about 15 minutes on the time line.
> >> 3) Click near the 10 minute mark on the empty track and generate 1
> >> second of a tone.
> >> 4) Zoom in on the tone so that it occupies 1/4 of the visible track.
> >> 5) Press F5 to select the Time Shift Tool
> >> 6) Click on the audio clip and drag to the left - the audio clip
> >> moves
> >> slower than the mouse pointer and the two become separated.
> >> 7) Without releasing the left mouse button - push the audio clip to
> >> the
> >> right - the audio clip now disappears off screen (exit stage left).
> >>
> >
> > Yeah, I'm seeing this. At first it appeared that the viewing window
> > was
> > scrolling as I dragged left (which is sort of true; the timeline
> > moves). The
> > audio clip moves relative to the timeline the same amount that the
> > mouse moves
> > relative to the screen. But it's not really that it's scrolling,
> > it's that
> > the timeline is shrinking. If the clip goes from 10:00 to 10:01,
> > the timeline
> > when you're zoomed in only goes out to about 10:02. As the clip is
> > dragged
> > left, say, to 9:58-9:59, the timeline will only extend to about
> > 10:00, so the
> > viewing window has to shift left. At least this is what I gather
> > without
> > looking at any code at all.
> >
> > (When I'm talking about the "timeline" here I'm not really talking
> > about
> > anything but the amount of ruler that can be scrolled to at a given
> > zoom level
> > -- as noted, this varies considerably at different zoom levels. I
> > don't know
> > how the code for this works yet.)
> >
> > As a result, if you zoom back out and add a short clip at 15:00, you
> > can see
> > this behavior on the clip at 15:00 but not on the clip at 10:00,
> > since it's no
> > longer the last clip in the timeline.
> >
> > Clearly the current behavior is not correct. But I think we have to
> > allow the
> > right edge of the timeline to move left as the last clip does.
> > Would you
> > consider it correct for the clip to move with the mouse as the
> > timeline
> > shrinks? My concern with this is that a user could drag the clip to
> > the left
> > edge of the screen and back and it would wind up in a different
> > place in time
> > (and the original location would probably be unavailable). Would it
> > be better
> > for the timeline not to shrink until a later time? At the
> > completion of the
> > time-shift might be weird, because then the whole display would snap-
> > move
> > right at the end of dragging. We could have the end of the timeline
> > not
> > change until it's scrolled off the screen (or a zoom action is
> > performed); this
> > might disrupt people dragging the scroll bar a little bit (unless we
> > also
> > didn't allow the shrink to happen while the scroll bar was held down).
> >
> > I can't look at the code right now; I think the last option would be
> > the
> > friendliest. Let the extra space remain viewable until it's been
> > scrolled off
> > the screen and the scrollbar isn't held down. But I'm not sure
> > whether that's
> > hard to do or not.
> >
> >> It may be worth looking at the P3 "Cursor jumps to start of scroll
> >> after
> >> playback cursor goes past scroll" at the same time as this issue,
> >> unless
> >> they are completely unrelated.
> >>
> >
> > I hadn't noticed this P3 before; it doesn't sound like they would be
> > related
> > in code, but you never know. It seems to really bother a few
> > people. Maybe
> > I'll take a look at that as well, since I think all the P2s are
> > either taken,
> > Windows-only, or things I can't repro.
> >
> > - a"w"d
> >
> > ------------------------------------------------------------------------------
> > Come build with us! The BlackBerry® 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/devconf
> > _______________________________________________
> > audacity-devel mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry® 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/devconf
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel

Bill Wharrie

Re: Problem with Time Shift tool when zoomed in

Reply Threaded

I think I can demonstrate that it's not scrolling but the timeline
shrinking:

new project
generate 10 minutes tone
new track
focus and select first track
skip to end
focus and select second (empty) track
generate 1 second tone
zoom in on the 1 second of tone by repeatedly clicking the zoom in
button
-- note how time at the right edge of the timeline changes with each
zoom
-- on my window the right edge was 10:03.0
with the time shift tool slowly drag the 1-second clip left
-- as you drag, the scroll/timeline-contraction will happen ...
-- until the right edge of the clip reaches the 10:00.0 mark
-- right edge of timeline now reads 10:02.0
-- then the effect stops
drag it back to its original position and the yellow snap line lights
up, let go
click and drag left again
-- no scrolling effect
-- note that right edge of timeline is still 10:02.0
zoom in one more click on the zoom-in button
-- right edge of timeline is now still about 10:02.0
drag 1-second clip left
-- scroll happens until right edge of timeline reads about 10:01.0

You can keep doing this (almost) forever.

It appears that at each zoom level Audacity has some time amount it
allows at the right edge of the timeline past the end of the longest
track. In the first instance above this was 2 seconds. As soon as the
clip was dragged before 10:00.0 and the right edge of the timeline
reached 10:02.0 the effect stopped. In the second instance the
"constant" time between the end of the longest track and the right
edge of the timeline was 1 second. And so on.

If the timeline was indeed shrinking and the clip knew this but the
pointer didn't (or vice versa) this could explain why the pointer and
the clip get out of sync.

On 4-Oct-09, at 10:46 PM, Gale Andrews wrote:

>
> | From Bill Wharrie <[hidden email]>
> | Sun, 4 Oct 2009 18:18:18 -0400
> | Subject: [Audacity-devel] Problem with Time Shift tool when zoomed
> in
>> OK, now I see what you're saying. If it is the only clip, or the last
>> clip, in the track, then Audacity is constantly redefining what the
>> "right edge of the track" is as you drag the clip left. At these
>> extreme zoom levels it *looks* like the track is scrolling (timeline
>> changes), but really what is happening is the right edge is
>> constantly
>> changing. The question is, why does the timeline need to shrink at
>> all? Is Audacity somewhere keeping track of the length of the longest
>> track to facilitate zoom-to-fit? If you waited until the drag was
>> finished and then updated this calculation would that cause the
>> display to jump?
>>
>> Similarly you can defeat this (wrong) effect by creating a 10-minute
>> track filled with tone then create a second track with 1 second of
>> tone at the 5-minute mark. Since Audacity thinks that the timeline
>> should be a minimum of 10 minutes long no shrinking occurs when you
>> drag the 1-second clip in the second track.
>>
>> Given that this effect occurs only when dragging the last clip in the
>> longest track, does this rate a P2?
>
> I haven't yet managed to get the timeline to display less length of
> time
> after drag here, and I call it that the timeline is scrolling, given
> if
> the cursor is by the selection when the scrolling starts, it will then
> disappear off-right while you are left-dragging the clip. As well as
> the scrolling, there can be a disconcerting change in the values
> presented on the timeline as you scroll (the timeline position you
> were aiming to align with no longer has an actual value attached to
> it).
>
> My 2p is that it's a P3 only. Would you often get in a position where
> you had zoomed in, so that you only had a short clip with a lot of
> white space around it, then wanted to time shift it a long way?
> If you did, it would be pretty tedious to drag it with the current
> "locking" of the clip after you reach the scroll.

Agreed.

>
> That doesn't stop anyone fixing it, but how sure are we that fixing
> it won't make something else even worse?

Agreed.

>
>
>
> Gale

-- Bill

>
>
>
>> On 4-Oct-09, at 1:44 PM, Al Dimond wrote:
>>
>>> On Sunday 04 October 2009 09:13:59 Steve wrote:
>>>> In certain situations when using the Time Shift tool, the mouse
>>>> pointer
>>>> becomes detached from the audio clip that is being moved.
>>>>
>>>> To reproduce the issue:
>>>>
>>>> 1) Open Audacity and add a new track.
>>>> 2) Zoom out so that you can see about 15 minutes on the time line.
>>>> 3) Click near the 10 minute mark on the empty track and generate 1
>>>> second of a tone.
>>>> 4) Zoom in on the tone so that it occupies 1/4 of the visible
>>>> track.
>>>> 5) Press F5 to select the Time Shift Tool
>>>> 6) Click on the audio clip and drag to the left - the audio clip
>>>> moves
>>>> slower than the mouse pointer and the two become separated.
>>>> 7) Without releasing the left mouse button - push the audio clip to
>>>> the
>>>> right - the audio clip now disappears off screen (exit stage left).
>>>>
>>>
>>> Yeah, I'm seeing this. At first it appeared that the viewing window
>>> was
>>> scrolling as I dragged left (which is sort of true; the timeline
>>> moves). The
>>> audio clip moves relative to the timeline the same amount that the
>>> mouse moves
>>> relative to the screen. But it's not really that it's scrolling,
>>> it's that
>>> the timeline is shrinking. If the clip goes from 10:00 to 10:01,
>>> the timeline
>>> when you're zoomed in only goes out to about 10:02. As the clip is
>>> dragged
>>> left, say, to 9:58-9:59, the timeline will only extend to about
>>> 10:00, so the
>>> viewing window has to shift left. At least this is what I gather
>>> without
>>> looking at any code at all.
>>>
>>> (When I'm talking about the "timeline" here I'm not really talking
>>> about
>>> anything but the amount of ruler that can be scrolled to at a given
>>> zoom level
>>> -- as noted, this varies considerably at different zoom levels. I
>>> don't know
>>> how the code for this works yet.)
>>>
>>> As a result, if you zoom back out and add a short clip at 15:00, you
>>> can see
>>> this behavior on the clip at 15:00 but not on the clip at 10:00,
>>> since it's no
>>> longer the last clip in the timeline.
>>>
>>> Clearly the current behavior is not correct. But I think we have to
>>> allow the
>>> right edge of the timeline to move left as the last clip does.
>>> Would you
>>> consider it correct for the clip to move with the mouse as the
>>> timeline
>>> shrinks? My concern with this is that a user could drag the clip to
>>> the left
>>> edge of the screen and back and it would wind up in a different
>>> place in time
>>> (and the original location would probably be unavailable). Would it
>>> be better
>>> for the timeline not to shrink until a later time? At the
>>> completion of the
>>> time-shift might be weird, because then the whole display would
>>> snap-
>>> move
>>> right at the end of dragging. We could have the end of the timeline
>>> not
>>> change until it's scrolled off the screen (or a zoom action is
>>> performed); this
>>> might disrupt people dragging the scroll bar a little bit (unless we
>>> also
>>> didn't allow the shrink to happen while the scroll bar was held
>>> down).
>>>
>>> I can't look at the code right now; I think the last option would be
>>> the
>>> friendliest. Let the extra space remain viewable until it's been
>>> scrolled off
>>> the screen and the scrollbar isn't held down. But I'm not sure
>>> whether that's
>>> hard to do or not.
>>>
>>>> It may be worth looking at the P3 "Cursor jumps to start of scroll
>>>> after
>>>> playback cursor goes past scroll" at the same time as this issue,
>>>> unless
>>>> they are completely unrelated.
>>>>
>>>
>>> I hadn't noticed this P3 before; it doesn't sound like they would be
>>> related
>>> in code, but you never know. It seems to really bother a few
>>> people. Maybe
>>> I'll take a look at that as well, since I think all the P2s are
>>> either taken,
>>> Windows-only, or things I can't repro.
>>>
>>> - a"w"d
>>>
>>> ------------------------------------------------------------------------------
>>> Come build with us! The BlackBerry® 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/devconf
>>> _______________________________________________
>>> audacity-devel mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>
>>
>> ------------------------------------------------------------------------------
>> Come build with us! The BlackBerry® 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/devconf
>> _______________________________________________
>> audacity-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry® 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/devconf
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel

Gale (Audacity Team)

Re: Problem with Time Shift tool when zoomed in

Reply Threaded

In reply to this post by Al Dimond

| From Al Dimond <[hidden email]>
| Sun, 4 Oct 2009 18:16:45 -0600
| Subject: [Audacity-devel] Problem with Time Shift tool when zoomed in

> On Sunday 04 October 2009 15:46:21 Gale Andrews wrote:
> > Hi Al
> >
> > I'm probably being "thick" but I'm not really following your argument.
> > Is the timeline "shrinking" when it moves? It isn't for me on Windows
> > XP. If I start with 10 seconds visible I still get 10 seconds visible
> > while the mouse progressively detaches from the clip.
> >
>
> What I'm saying is that before starting to time shift the latest point in time
> that you can scroll to is 10:02.00 (around a second after the end of the
> clip). After time-shifting the clip 2 seconds back, the latest point in time
> that you can scroll to is 10:00.00 (again, around a second after the end of
> the clip). At different zoom levels the amount of time may vary. As far as I
> can tell (I haven't looked at the code yet) the fact that this "end of
> timeline" point is constantly moving back forces a backwards scroll that the
> time-shifting code doesn't account for.

That's understood. I think it's the term "shrinking" I was having
trouble with, which conveyed to me that less length of time was being
displayed in the timeline purely by reason of the "end of timeline"
point changing.

> Ultimately this "end of timeline" point has to move; if you time-shift the
> last clip all the way from 10 minutes to 9 minutes (this is hard to imagine
> the way the tool currently works, but if your suggested change below were
> implemented it would be easy), you want the scroll bars to reflect the fact
> that you have a 9-minute long project, not a 10-minute long one.

Thanks. I can imagine (and see the effect on the horizontal scrollbar)
if I cut the only 1-second clip situated at 10:00 seconds and paste it
at say 3 seconds.

> But the change should not occur while dragging around a clip with the
> time-shift tool.

Agreed.

> Maybe it should take effect right after the time-shift, or maybe the extra
> space remain possible-to-scroll-to until it's scrolled off-screen.

It looks like the latter (as you said) might "appear" the most friendly
to the user, but the former makes it clearer that the end of timeline
point has changed and why. Not easy to say until we had demos to try.

> > Why does the timeline have to move left with the last clip, but not with
> > others? That isn't consistent behaviour. One thing that is consistent
> > with any clips is that when you drag it left or right you can't take
> > it any farther when it reaches the end of the scroll. This may be a
> > longer term decision, but would it be better if a scroll was initiated
> > when the end was reached, to save the extra step of zooming out
> > or using the horizontal scroll bar to complete the drag? Or I
> > suppose you could always scroll when dragging, even within the
> > scroll width, but I would feel a bit disorientated by that.
> >
>
> I agree with this. Auto-scroll behavior in the time-shift tool ought to work
> just like it does in the selection tool. I think this is more of a feature
> request than a bug, though.

Definitely an "enhancement".

Thanks

Gale

------------------------------------------------------------------------------
Come build with us! The BlackBerry® 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/devconf
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Al Dimond

Re: Problem with Time Shift tool when zoomed in

Reply Threaded

On Sunday 04 October 2009 22:20:15 Gale Andrews wrote:
>
> > Maybe it should take effect right after the time-shift, or maybe the
> > extra space remain possible-to-scroll-to until it's scrolled off-screen.
>
> It looks like the latter (as you said) might "appear" the most friendly
> to the user, but the former makes it clearer that the end of timeline
> point has changed and why. Not easy to say until we had demos to try.
>

Well, attached is a patch that gives the former. It's not very many lines of
code, but it took me a long time to figure out where to put them. I don't
think the behavior is too horrible... I need to sleep now, I'll have a patch
for the second option tomorrow morning.

- Al

[awd_slide_scroll_fix.patch]

Index: src/Project.cpp =================================================================== RCS file: /cvsroot/audacity/audacity-src/src/Project.cpp,v retrieving revision 1.456 diff -u -r1.456 Project.cpp --- src/Project.cpp 30 Sep 2009 19:31:44 -0000 1.456 +++ src/Project.cpp 5 Oct 2009 05:51:46 -0000 @@ -1288,7 +1288,13 @@ // Add 1/4 of a screen of blank space to the end of the longest track mViewInfo.screen = ((double) panelWidth) / mViewInfo.zoom; - mViewInfo.total = mTracks->GetEndTime() + mViewInfo.screen / 4; + double newTotal = mTracks->GetEndTime() + mViewInfo.screen / 4; + + // Don't decrease total if the track panel doesn't want it. + if (newTotal > mViewInfo.total || !mTrackPanel->DoNotDecreaseTotalLength()) + { + mViewInfo.total = newTotal; + } if (mViewInfo.h > mViewInfo.total - mViewInfo.screen) { mViewInfo.h = mViewInfo.total - mViewInfo.screen; Index: src/TrackPanel.h =================================================================== RCS file: /cvsroot/audacity/audacity-src/src/TrackPanel.h,v retrieving revision 1.140 diff -u -r1.140 TrackPanel.h --- src/TrackPanel.h 10 Sep 2009 06:28:25 -0000 1.140 +++ src/TrackPanel.h 5 Oct 2009 05:51:47 -0000 @@ -222,6 +222,10 @@ void UpdateTrackVRuler(Track *t); void UpdateVRulerSize(); + // Returns true if it would be inappropriate to decrease viewInfo.total due + // to current activity (during sliding is one case... there may be others) + bool DoNotDecreaseTotalLength() { return mMouseCapture == IsSliding; }; + private: #ifdef EXPERIMENTAL_MIXER_BOARD MixerBoard* GetMixerBoard();

Al Dimond

Re: Problem with Time Shift tool when zoomed in

Reply Threaded

On Sunday 04 October 2009 23:54:52 Al Dimond wrote:

> On Sunday 04 October 2009 22:20:15 Gale Andrews wrote:
> > > Maybe it should take effect right after the time-shift, or maybe the
> > > extra space remain possible-to-scroll-to until it's scrolled
> > > off-screen.
> >
> > It looks like the latter (as you said) might "appear" the most friendly
> > to the user, but the former makes it clearer that the end of timeline
> > point has changed and why. Not easy to say until we had demos to try.
>
> Well, attached is a patch that gives the former. It's not very many lines
> of code, but it took me a long time to figure out where to put them. I
> don't think the behavior is too horrible... I need to sleep now, I'll have
> a patch for the second option tomorrow morning.
>
> - Al

And here's the patch for the latter (it keeps extra space at the end of the
timeline visible until it's scrolled or zoomed off screen). Be sure to reverse
my first patch before applying. It's even shorter than the first one (if I had
realized how easy it would be I would have done it before going to bed last
night).

This behavior is nice for not jerking the view around, but is annoying in some
ways. If, for example, you have the test project with some audio in the first
minute and then a clip 10 minutes out, then delete the clip 10 minutes out,
you're still stuck viewing out in the middle of nowhere; since the cursor is
still out there, even zooming in and out doesn't change that. You have to
scroll back to the audio, which has an interesting effect -- instead of the
scroll bar moving as you drag it, it grows.

In this patch I was intending the effects on actions other than time-shifting,
and didn't know whether they'd be better or worse than existing behavior.
After testing I think they're worse. And so, in my mind, the first patch wins.
It's a subjective thing, so I'd like to hear what anyone else has to say.
Also, just checking for sanity on non-Unix platforms.

Both patches should continue to work fine if/when we add autoscroll during the
timeshift (like we have while dragging out selections).

- Al

[awd_slide_scroll_fix_2.patch]

Gale (Audacity Team)

Re: Problem with Time Shift tool when zoomed in

Reply Threaded

| From Al Dimond <[hidden email]>
| Mon, 5 Oct 2009 11:21:24 -0600
| Subject: [Audacity-devel] Problem with Time Shift tool when zoomed in

> On Sunday 04 October 2009 23:54:52 Al Dimond wrote:
> > On Sunday 04 October 2009 22:20:15 Gale Andrews wrote:
> > > > Maybe it should take effect right after the time-shift, or maybe the
> > > > extra space remain possible-to-scroll-to until it's scrolled
> > > > off-screen.
> > >
> > > It looks like the latter (as you said) might "appear" the most friendly
> > > to the user, but the former makes it clearer that the end of timeline
> > > point has changed and why. Not easy to say until we had demos to try.
> >
> > Well, attached is a patch that gives the former. It's not very many lines
> > of code, but it took me a long time to figure out where to put them. I
> > don't think the behavior is too horrible... I need to sleep now, I'll have
> > a patch for the second option tomorrow morning.
> >
> > - Al
>
> And here's the patch for the latter (it keeps extra space at the end of the
> timeline visible until it's scrolled or zoomed off screen). Be sure to reverse
> my first patch before applying. It's even shorter than the first one (if I had
> realized how easy it would be I would have done it before going to bed last
> night).
>
> This behavior is nice for not jerking the view around, but is annoying in some
> ways. If, for example, you have the test project with some audio in the first
> minute and then a clip 10 minutes out, then delete the clip 10 minutes out,
> you're still stuck viewing out in the middle of nowhere; since the cursor is
> still out there, even zooming in and out doesn't change that. You have to
> scroll back to the audio, which has an interesting effect -- instead of the
> scroll bar moving as you drag it, it grows.
>
> In this patch I was intending the effects on actions other than time-shifting,
> and didn't know whether they'd be better or worse than existing behavior.
> After testing I think they're worse. And so, in my mind, the first patch wins.
> It's a subjective thing, so I'd like to hear what anyone else has to say.
> Also, just checking for sanity on non-Unix platforms.
>
> Both patches should continue to work fine if/when we add autoscroll during the
> timeshift (like we have while dragging out selections).
>
>
> - Al

After a fair amount of testing I've come out strongly in favour of the
second patch.

* I just don't think scrolling the screen (as I call it, that we had
before) or snapping the clip back after dragging is a good
user experience.

* I think it's reasonable for the cursor to stay put when you
delete the last clip, as it does in the second patch. Why shunt
the user back to zero and remove the timeline area they
were looking at? Suppose they wanted to do something else
there? If they didn't, just hit HOME. Better than having to zoom
back out to figure where you were with the first patch.

* The second patch also makes it easy to drag the final 1-second
clip leftwards (say from 10:00 to 09:57 where you have about
09:57 to 10:02 visible on the timeline), then insert audio up to
four times as long as the clip after the end of it. Using the time
shift tool to make the space first to see what you're doing would
seem intuitive, but only the second patch lets us do that.

What worse behaviour with the second patch did you find with effects?
I did not test much with those.

Also note that we already have another form of snapping with both
patches and current behaviour, if you shift the test clip left then hit
END to move to the end of the project - the clip jumps rightwards,
further reducing the space at the end of the timeline. I find this
disconcerting (especially if you are zoomed out) and not at all useful.
Unless someone has a use case for it I'm missing, I'd say END should
never visually move the timeline unless it actually needs to move
outside the scroll.

Gale

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

Re: Problem with Time Shift tool when zoomed in

Reply Threaded

On Thursday 08 October 2009 20:54:10 Gale Andrews wrote:

> After a fair amount of testing I've come out strongly in favour of the
> second patch.
>
> * I just don't think scrolling the screen (as I call it, that we had
> before) or snapping the clip back after dragging is a good
> user experience.
>
> * I think it's reasonable for the cursor to stay put when you
> delete the last clip, as it does in the second patch. Why shunt
> the user back to zero and remove the timeline area they
> were looking at? Suppose they wanted to do something else
> there? If they didn't, just hit HOME. Better than having to zoom
> back out to figure where you were with the first patch.
>
> * The second patch also makes it easy to drag the final 1-second
> clip leftwards (say from 10:00 to 09:57 where you have about
> 09:57 to 10:02 visible on the timeline), then insert audio up to
> four times as long as the clip after the end of it. Using the time
> shift tool to make the space first to see what you're doing would
> seem intuitive, but only the second patch lets us do that.
>
> What worse behaviour with the second patch did you find with effects?
> I did not test much with those.
>

I think my sentence was unclear there. I was referring to the effect the patch
had on the action of deleting audio way out at the end of tracks.

At any rate, good points, you pretty much have me convinced. I think in my
testing I was (a) looking mostly at very contrived cases and (b) desensitized
to snapping because I was expecting it.

Thanks for giving these patches a good test run.

> Also note that we already have another form of snapping with both
> patches and current behaviour, if you shift the test clip left then hit
> END to move to the end of the project - the clip jumps rightwards,
> further reducing the space at the end of the timeline. I find this
> disconcerting (especially if you are zoomed out) and not at all useful.
> Unless someone has a use case for it I'm missing, I'd say END should
> never visually move the timeline unless it actually needs to move
> outside the scroll.
>
>

Hm, I wouldn't have expected that hitting END would do that (I can think of a
couple reasons why it might, though). I'll look at that tomorrow (along with
a weird pasting bug I just found while investigating one of the P3s... but
that's for another thread).

>
>
> Gale
>
>
>
>
> ---------------------------------------------------------------------------
> --- 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
>

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

Re: Problem with Time Shift tool when zoomed in

Reply Threaded

On Thursday 08 October 2009 22:45:35 Al Dimond wrote:

> > Also note that we already have another form of snapping with both
> > patches and current behaviour, if you shift the test clip left then hit
> > END to move to the end of the project - the clip jumps rightwards,
> > further reducing the space at the end of the timeline. I find this
> > disconcerting (especially if you are zoomed out) and not at all useful.
> > Unless someone has a use case for it I'm missing, I'd say END should
> > never visually move the timeline unless it actually needs to move
> > outside the scroll.
>
> Hm, I wouldn't have expected that hitting END would do that (I can think of
> a couple reasons why it might, though). I'll look at that tomorrow (along
> with a weird pasting bug I just found while investigating one of the
> P3s... but that's for another thread).
>

This patch takes care of hitting END. It uses the existing
TrackPanel::ScrollIntoView(), which does, as far as I can tell, exactly what
we want.

- Al

[awd_end_no_snap.patch]

Index: src/Project.cpp =================================================================== RCS file: /cvsroot/audacity/audacity-src/src/Project.cpp,v retrieving revision 1.457 diff -u -r1.457 Project.cpp --- src/Project.cpp 7 Oct 2009 23:31:41 -0000 1.457 +++ src/Project.cpp 9 Oct 2009 06:44:12 -0000 @@ -3583,20 +3616,9 @@ if (!shift || mViewInfo.sel0 > mViewInfo.sel1) mViewInfo.sel0 = len; - //STM: Determine wisely where to position the viewport - // There are two conditions: - // - // (1) If the total width of the sample is larger than the viewport - // is wide, sets the viewport so that the end of the sample will - // have about 5% empty space after it - // (2) If the total width of the sample is less than the viewport is - // wide, set the viewport's left edge to be 0. - - //Calculates viewstart: End of sample - 95% of a screen width - double viewstart = len - mViewInfo.screen * .95; - viewstart = viewstart > 0 ? viewstart : 0.0; - - TP_ScrollWindow(viewstart); + // Make sure the end of the track is visible + mTrackPanel->ScrollIntoView(len); + mTrackPanel->Refresh(false); }

Gale (Audacity Team)

Re: Problem with Time Shift tool when zoomed in

Reply Threaded

| From Al Dimond <[hidden email]>
| Fri, 9 Oct 2009 00:50:46 -0600
| Subject: [Audacity-devel] Problem with Time Shift tool when zoomed in

> On Thursday 08 October 2009 22:45:35 Al Dimond wrote:
> > > Also note that we already have another form of snapping with both
> > > patches and current behaviour, if you shift the test clip left then hit
> > > END to move to the end of the project - the clip jumps rightwards,
> > > further reducing the space at the end of the timeline. I find this
> > > disconcerting (especially if you are zoomed out) and not at all useful.
> > > Unless someone has a use case for it I'm missing, I'd say END should
> > > never visually move the timeline unless it actually needs to move
> > > outside the scroll.
> >
> > Hm, I wouldn't have expected that hitting END would do that (I can think of
> > a couple reasons why it might, though). I'll look at that tomorrow (along
> > with a weird pasting bug I just found while investigating one of the
> > P3s... but that's for another thread).
> >
>
> This patch takes care of hitting END. It uses the existing
> TrackPanel::ScrollIntoView(), which does, as far as I can tell, exactly what
> we want.

Thanks Al. That patch looks excellent to me, and with the second version
of the slide_scroll_patch that does not have the snapping after drag, a
really good solution.

Anyone disagree with committing those two patches?

Gale

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

Gale (Audacity Team)

Re: Problem with Time Shift tool when zoomed in

Reply Threaded

Gale (Audacity Team) wrote:
| From Al Dimond <businessmanprogrammersteve@gmail.com>
| Fri, 9 Oct 2009 00:50:46 -0600
| Subject: [Audacity-devel] Problem with Time Shift tool when zoomed in
>> On Thursday 08 October 2009 22:45:35 Al Dimond wrote:
>> > > Also note that we already have another form of snapping with both
>> > > patches and current behaviour, if you shift the test clip left then hit
>> > > END to move to the end of the project - the clip jumps rightwards,
>> > > further reducing the space at the end of the timeline. I find this
>> > > disconcerting (especially if you are zoomed out) and not at all useful.
>> > > Unless someone has a use case for it I'm missing, I'd say END should
>> > > never visually move the timeline unless it actually needs to move
>> > > outside the scroll.
>> >
>> > Hm, I wouldn't have expected that hitting END would do that (I can think of
>> > a couple reasons why it might, though). I'll look at that tomorrow (along
>> > with a weird pasting bug I just found while investigating one of the
>> > P3s... but that's for another thread).
>> >
>>
>> This patch takes care of hitting END. It uses the existing
>> TrackPanel::ScrollIntoView(), which does, as far as I can tell, exactly what
>> we want.
>
> Thanks Al. That patch looks excellent to me, and with the second version
> of the slide_scroll_patch that does not have the snapping after drag, a
> really good solution.
>
> Anyone disagree with committing those two patches?

I've gone ahead and committed both given there were no disagreements.

Gale