Audacity Forum

Gale Andrews wrote:First, it's slow. With 40 tracks on Windows 7, after Move Track Up or Down, I'm waiting for more than five seconds looking at a History box first with a whited out list, , and then the whole History window whited out.

Really?
It's virtually instant here. I wonder why the difference. Is that always the case when there are more than a couple of dozen items in the History, or is it specific the "Move Track" items? Either way it should probably go on bugzilla, assuming that it is repeatable on other machines.

Gale Andrews wrote:Second, if I move a track from top to bottom of 40 tracks using "Move Track to Bottom", I expect to undo that in one undo, not iterate on CTRL + Z trying to guess how many undos I need.

I agree that one undo is the more expected behaviour, and it is very easy to modify the patch to do that, but the point of one undo per move is that it provides a much quicker way to move a track an arbitrary number of places.

Example: You have 30 tracks and you want to move track 27 to the 4th track from the top:
1) Move to top (27 -> 1)
2) Ctrl+Z (1 -> 2)
3) Ctrl+Z (2->3)
4) Ctrl+Z (3->4)

Personally I find this a lot more useful than one undo all the way back. If this is too radical then I don't mind changing it, but I'd prefer to first get feedback from users that work a lot with large mult-track projects, and I don't think that we can get that feedback without releasing it with this behaviour.

Gale Andrews wrote:Also Move Track Up/Down/to Bottom/Top raises the question of whether the view should move with the track that's been moved. Suppose I have the first four tracks of 40 tracks visible, track one selected and focused, and move the fourth track down using the mouse. I don't see the track I moved any longer. Maybe that's OK. But suppose the fourth track is focused - I still don't see the track I moved. Should we not always be able to see the focused track if we have explicitly moved it?

I think that can be argued either way.
You may have 40 tracks and be working on tracks 1,2 and 5, so you want to move tracks 3 and 4 down to the bottom out of the way. In this case you would want the view to remain in its current position.

Perhaps we need additional View menu commands?
View > Selection (zooms and moves to fit as much of the selection as possible in the visible area).
View > Focus (moves to the track that has focus - this could perhaps assist VI users by reading out the track information of the track with focus).

steve wrote:

Gale Andrews wrote:First, it's slow. With 40 tracks on Windows 7, after Move Track Up or Down, I'm waiting for more than five seconds looking at a History box first with a whited out list, , and then the whole History window whited out.

Really?
It's virtually instant here. I wonder why the difference. Is that always the case when there are more than a couple of dozen items in the History, or is it specific the "Move Track" items? Either way it should probably go on bugzilla, assuming that it is repeatable on other machines.

It may be a problem with too many tracks?

If I have one track I can CTRL + R an effect dozens of times without the history window freezing.

If I have one track and hold CTRL + D (duplicate) down, Audacity will quickly freeze up, with or without History open. Does it do that on a fast Linux machine like yours?

If I do Move Track to Bottom on the top track of 40 tracks, without the History window open, then I sit looking at the Drop-Down Menu button in depressed state for five or six seconds.

steve wrote:

Gale Andrews wrote:Second, if I move a track from top to bottom of 40 tracks using "Move Track to Bottom", I expect to undo that in one undo, not iterate on CTRL + Z trying to guess how many undos I need.

I agree that one undo is the more expected behaviour, and it is very easy to modify the patch to do that, but the point of one undo per move is that it provides a much quicker way to move a track an arbitrary number of places.

Example: You have 30 tracks and you want to move track 27 to the 4th track from the top:
1) Move to top (27 -> 1)
2) Ctrl+Z (1 -> 2)
3) Ctrl+Z (2->3)
4) Ctrl+Z (3->4)

Personally I find this a lot more useful than one undo all the way back. If this is too radical then I don't mind changing it, but I'd prefer to first get feedback from users that work a lot with large mult-track projects, and I don't think that we can get that feedback without releasing it with this behaviour.

I think it's too radical, doesn't do what's on the can (buzz phrase) and few users would be smart enough to realise they could use CTRL + Z that way.

I think it would be much better to have "Undo Move Track to Top" (or Bottom) on one undo, and see if anyone suggests it should create per track undos instead. And consider if we can make direct shortcuts for Drop-Down Menu items available.

Can you do an alternative patch that only has one Undo on move to top or bottom? Then I can see if even that is slow here (I don't think it would be, but we should find out).

steve wrote:

Gale Andrews wrote:Also Move Track Up/Down/to Bottom/Top raises the question of whether the view should move with the track that's been moved. Suppose I have the first four tracks of 40 tracks visible, track one selected and focused, and move the fourth track down using the mouse. I don't see the track I moved any longer. Maybe that's OK. But suppose the fourth track is focused - I still don't see the track I moved. Should we not always be able to see the focused track if we have explicitly moved it?

I think that can be argued either way.
You may have 40 tracks and be working on tracks 1,2 and 5, so you want to move tracks 3 and 4 down to the bottom out of the way. In this case you would want the view to remain in its current position.

Perhaps we need additional View menu commands?
View > Selection (zooms and moves to fit as much of the selection as possible in the visible area).

What's the difference between that and View > Fit Vertically? You mean it strictly depends on the number of selected tracks?

steve wrote:View > Focus (moves to the track that has focus - this could perhaps assist VI users by reading out the track information of the track with focus).

Not sure. That assumes the default would be not to move to the track that has focus.

Also should whether the view always goes to the focused track be a "Behavior" in the Tracks Preferences? Perhaps there are not enough cases where it doesn't go to the focused track to have such a preference?


Gale

Gale Andrews wrote:If I have one track and hold CTRL + D (duplicate) down, Audacity will quickly freeze up, with or without History open. Does it do that on a fast Linux machine like yours?

My Linux machine is not particularly "high power". It has 3 GB of ram and was the cheapest laptop that I could find about 4 or 5 years ago.
Audacity starts to get generally a bit sluggish when there are more than about 50 tracks.

As the number and length of tracks increases I notice that dragging tracks up/down has to be done slowly. If the pointer is moved too fast the dragged track gets left behind. With 32 tracks, each of about 16 minutes duration, dragging cannot be much faster than one place per second. Undo will take about half a second for each track. For shorter tracks, say 3 minutes each, then even with 64 tracks there is no noticeable slow down when dragging tracks or undoing.

Gale Andrews wrote:I think it's too radical

Perhaps it is.

Gale Andrews wrote:Can you do an alternative patch that only has one Undo on move to top or bottom? Then I can see if even that is slow here (I don't think it would be, but we should find out).

Certainly.

Gale Andrews wrote:

steve wrote: Perhaps we need additional View menu commands?
View > Selection (zooms and moves to fit as much of the selection as possible in the visible area).

What's the difference between that and View > Fit Vertically?

Lets say that you have 40 tracks.
Make a selection in tracks 35, 36 and 37.
Scroll up to the top.
"View > Selection".
The track window scrolls up so that track 35 is at the top of the visible window area and is zoomed horizontally to fit the selection.

One place where this would be very useful is that it solves the question of whether "Move Track To Bottom" should scroll the window or not. The behaviour could be "don't scroll, but if the occasion calls for scrolling then scrolling down is only one click away.

Gale Andrews wrote:That assumes the default would be not to move to the track that has focus.

Is there a compelling reason why the project should scroll to keep the focussed track visible? I've suggested one case where that behaviour would definitely not be wanted.

Gale Andrews wrote:Can you do an alternative patch that only has one Undo on move to top or bottom?

Attached. I'm not really sure what is required for translation hints, so please feel free to modify those as necessary.

steve wrote:

Gale Andrews wrote:

steve wrote: Perhaps we need additional View menu commands?
View > Selection (zooms and moves to fit as much of the selection as possible in the visible area).

What's the difference between that and View > Fit Vertically?

Lets say that you have 40 tracks.
Make a selection in tracks 35, 36 and 37.
Scroll up to the top.
"View > Selection".
The track window scrolls up so that track 35 is at the top of the visible window area and is zoomed horizontally to fit the selection.

One place where this would be very useful is that it solves the question of whether "Move Track To Bottom" should scroll the window or not. The behaviour could be "don't scroll, but if the occasion calls for scrolling then scrolling down is only one click away.

I like the idea of a View command that does that, though it would not not entirely solve the question of whether "Move Track to Bottom" should scroll because your solution doesn't cover people who want to move unselected tracks and still see them.

steve wrote:

Gale Andrews wrote:That assumes the default would be not to move to the track that has focus.

Is there a compelling reason why the project should scroll to keep the focussed track visible? I've suggested one case where that behaviour would definitely not be wanted.

"Compelling" would be too strong but there will be cases where you want to move the track and work on it in its new position.

If you drag the track then obviously the view scrolls with the track. I find it disconcerting to have e.g. a third stereo track filling the whole project height, choose Move Track Down, then I am left looking at the fourth stereo track.



Gale

Gale Andrews wrote:I like the idea of a View command that does that, though it would not not entirely solve the question of whether "Move Track to Bottom" should scroll because your solution doesn't cover people who want to move unselected tracks and still see them.

Yes, and that's why the second option "View > Focus".
This option does basically the same, but for the track that has focus rather than the selected track.
Am I right in thinking that a track must have focus in order to move it?

Robert J. H. wrote:

Gale Andrews wrote:

Robert J. H. wrote:undo moves the focus to the first track

It's a bug: http://bugzilla.audacityteam.org/show_bug.cgi?id=510 .

In your example (rename the fourth track, move it up, undo move) is it most useful for the focus to move back to the fourth track, or stay on the third track? Generally (as a sighted user) I expect the focus to stay put after undo, but when the thing being undone had moved the focus, I'm not so sure.
Gale

For this case, it would be most convenient when the focus is not affected by the undo.

Can you clarify, Robert? After undo, should the focus remain on the third track, or move back to the fourth track (so that focus remains with the track that moves)?


Gale

Gale Andrews wrote:

Robert J. H. wrote:

Gale Andrews wrote:

Robert J. H. wrote:undo moves the focus to the first track

It's a bug: http://bugzilla.audacityteam.org/show_bug.cgi?id=510 .

In your example (rename the fourth track, move it up, undo move) is it most useful for the focus to move back to the fourth track, or stay on the third track? Generally (as a sighted user) I expect the focus to stay put after undo, but when the thing being undone had moved the focus, I'm not so sure.
Gale

For this case, it would be most convenient when the focus is not affected by the undo.

Can you clarify, Robert? After undo, should the focus remain on the third track, or move back to the fourth track (so that focus remains with the track that moves)?


Gale

I'm struggling at the moment with the application of the patch...
I must admit, I am not very proficient in that. Tortoise's merge tool isn't very accessible. If one could give me a hint what one should exactly do, this would be nice.
However, I've succeeded so far in implementing the latest patch (with one undo step).
It is really nice. I'll stick with it for the time being.
It's a nuisance that the focus springs back to the first track after undo that's why I've not installed the multiple undo step version of the patch.
As I've already stated in another thread, the undo command should all reset to the state before the effect/command in question has been applied.
This should include:
- Selected tracks
- Mute/Solo
- Focus
Currently, these states are not reset to the point just before the undo step.
I've explained in the post you've quoted, Gayle, that for the case that undo serves as "Navigator" after move to top/bottom the focus could alternatively remain in the position before pressing undo.
For example: You send the 10th track to the top. You move the focus to the 4th track, and you do apply undo (focus still on the 4th track) until the first (previously moved) track is at the 4th position (which is announced by the screen reader).
However, this is a specific situation and it might still be better to set the focus just where it was before the restore point was saved.
Example for this: You send the 10th track to the top - focus is on the first track. Then, you click undo. It now depends which patch is in action - single or multiple undo. In any case will the focus remain (or rather follow) on the track that had focus before "Move to top".

It is the same behaviour that "Move Track Up/Down" already has (not after undo of course).
We must probably abandon the multiple undo version as a navigation help, instead we should focus on introducing hotkeys to the context/drop down menu.
I propose that we do that not with all commands but with those that make the most sense. The move commands belong to this category and also the split/make stereo track entries.

I'm inclined to agree with Robert on the "focus", "undo" and "hot key" issues, but these issues are well outside of the scope of what this patch sets out to do. I've no intention of adding more features to this patch because (at around 13,000 characters) it is already quite a big patch, and if I start adding more to it then none of the developers will review the code and these features will never happen.

Initially I was a bit sceptical about these new commands, but Gale convinced me that it was worth doing, and having implemented it I can see that it is useful. If these new commands are accepted into the code base, then I think we can build on this and look at adding hotkey access, but we first need to decide if we want the "Move to Top" Move to Bottom" and "Swap channels" commands (or not). I'm +1 for adding these commands.

+1 from me too.
Really good job, Steve.
By the way, the new keyboard preferences layout looks pretty good in the upcoming version 2.0.6. Hopefully, the track drop down menu will yet become a branch of the tree...