Audacity Forum

Robert, I presume that you use Jaws with Audacity?
I'm not familiar with Jaws, but I gather there is some sort of customisation script that improves Audacity's accessibility, is that correct?

When you use the current "Move Track Up / Down" commands, what feedback do you get from Jaws about the track position?

steve wrote:Robert, I presume that you use Jaws with Audacity?
I'm not familiar with Jaws, but I gather there is some sort of customisation script that improves Audacity's accessibility, is that correct?

When you use the current "Move Track Up / Down" commands, what feedback do you get from Jaws about the track position?

I am using NVDA. It is all written in python. I am not aware of any special Audacity script.
When you're on a track, it says something like:
"Bass-guitar mute solo select on 3 of 4"
"Mute" and "Solo" are of course only read if they are enabled. "3 of 4" indicates the position.
If I use "Move Track Up", the focus will follow the moved track and the whole information from above is read again, except that the position is now "2 of 4".
Jaws does it in the same manner. It has its own scripting language (quite comfortable to program by the way). However, it doesn't run on my Windows 7 64-bit, only on my laptop.

steve wrote: One of the few menus that has a variable number of menu items is the Effect menu, but even that has a problem that it can only update on launch. If effects are added or removed while Audacity is running, the menus fall out of sync. No solution has yet be found - it's not an easy problem.

I think this example is a little misleading. Menu items may be removed or added on the fly with the understanding that they will not be removed or added visually until the next time the menu is reopened. I think the reason that it's difficult with effects is because the code which builds the effects menu is is based on the Command Manager code which probably only runs once.

Have y'all considered using a right-click context menu to split off some of these chores? I have not tried it but I suspect you could create a OnRightClick () function for the track info panel.

Edgar wrote:Have y'all considered using a right-click context menu to split off some of these chores?

That would not be accessible for non-mouse users would it? Accessibility is very important to this feature - after all, mouse users can just drag tracks into the order they want.

Actually I'm quite happy with just adding the new commands to the main drop-down menu now that I've found sensible access keys for them. I just need to update the access keys, then I'll post a patch for y'all to try.

I know that Robert said "I am not so fond of little undo steps", but I'm finding that it is extremely convenient to be able to "scroll" a track up and down with "Undo" and "Redo". I find that it makes moving tracks quick and accurate - in large projects it's easier than using a mouse to drag the tracks.

I wonder how many people change waveform view on the fly? Putting just those in a sub-menu would reduce the complexity and mean no current access keys would need to change.

Ideally if there was space it could be better to have one menu for the name, position and assignment choices and another for rate, depth and view choices (having a spanner button or similar). I suppose that would have to be a dialogue rather than a drop-down menu.

Gale

steve wrote:I know that Robert said "I am not so fond of little undo steps", but I'm finding that it is extremely convenient to be able to "scroll" a track up and down with "Undo" and "Redo". I find that it makes moving tracks quick and accurate - in large projects it's easier than using a mouse to drag the tracks.

True, I'll be content with it. The project will in any case be saved after rearrangement.
By the way, is there any reason why the drop down menu isn't listed in the keyboard section of the preferences dialog?
If it were the case, I'd simply assign the move up and down commands to Pg up and Pg down.

Robert J. H. wrote:By the way, is there any reason why the drop down menu isn't listed in the keyboard section of the preferences dialog?
If it were the case, I'd simply assign the move up and down commands to Pg up and Pg down.

There is one track drop-down menu for every track. Each track has its own drop-down menu. This has some interesting repercussions in both the code and in a practical user way. For users it means that the menu will affect the track that the menu belongs to, and not the track that is selected or the track that has focus. You could think of it as the keyboard preferences having global scope, whereas the scope of the drop-down menu is limited to the track that the menu belongs to.

When I previously wrote "it might be worth taking quite a different approach", what I had in mind was an "Effect" to move tracks. An effect could be as simple or complex as we want, and as it would be part of the project menu, it would be available to the keyboard preferences. Also, it would affect selected tracks rather than the track that has focus. In the simplest case, this would mean that you could, for example, assign "Pg Up" and "Pg Down" to move the selected tracks up or down. This would be a different feature to the one being discussed in this topic.

Gale Andrews wrote:I wonder how many people change waveform view on the fly? Putting just those in a sub-menu would reduce the complexity and mean no current access keys would need to change.

Do you mean, putting Waveform, Waveform dB, Spectrogram, Spectrogram log(f) and Pitch (EAC) into a "Track View" sub menu? My main concern about doing that would be that it reduces the visibility of the Spectrogram option, which is a very useful feature for seeing the precise location of clicks and other artefacts.

Apart from that, I think that "U" and "D" for "Move Up" and "Move Down" is a good change. "P" should never have been used in the first place because on many machines the underscore is invisible. Having "V" and "W" for "Waveform" and "Waveform dB" makes a lot of sense (in English). "I" for "Split" is probably more memorable than "T" for "Split" as there are so many other "T" words (such as "T" for "Top"). Personally I think these changes are good even before considering the need to for accommodating the new commands.

steve wrote:

Robert J. H. wrote:By the way, is there any reason why the drop down menu isn't listed in the keyboard section of the preferences dialog?
If it were the case, I'd simply assign the move up and down commands to Pg up and Pg down.

There is one track drop-down menu for every track. Each track has its own drop-down menu. This has some interesting repercussions in both the code and in a practical user way. For users it means that the menu will affect the track that the menu belongs to, and not the track that is selected or the track that has focus. You could think of it as the keyboard preferences having global scope, whereas the scope of the drop-down menu is limited to the track that the menu belongs to.

Sorry, but that's hardly a reason, it's rather an obstacle for the programmer. Many menu commands do not care what is selected (play for example). In its simplest form, the key assignement could simply send "shift-m" and "u" to the keyboard buffer.
Anyway, this is a little off-topic. I'll consider it and have a look at the source code myself.
There's also the possibility to program such a thing directly for the screen reader.

steve wrote:When I previously wrote "it might be worth taking quite a different approach", what I had in mind was an "Effect" to move tracks. An effect could be as simple or complex as we want, and as it would be part of the project menu, it would be available to the keyboard preferences. Also, it would affect selected tracks rather than the track that has focus. In the simplest case, this would mean that you could, for example, assign "Pg Up" and "Pg Down" to move the selected tracks up or down. This would be a different feature to the one being discussed in this topic.

And then there's the point where you have selected tracks with gaps between.
Two possibilities (e.g. by sending them to the top):
- The gaps are preserved, i.e. all tracks are moved by the same amount.
- they are collected at the top, i.e. the last is sent to the top then the second last and so on.
This raises the problem, what the undo function exactly affects.
The first possibility is easier; one upwards motion of the selected tracks can be collected into one undo step.
The second one has numerous solutions and is difficult to predict for the user.

Back to the current proposal and something that is only a problem for VI users.
Sighted users can move the track up until it is at the right position because they see what's above and below the track. The same thing with first sending the track to the top and then undoing.
I have always to move the focus to a neighbouring track to control if I am yet at the right position. That's why choosing the target position from a list would have been so convenient.
There's at least one improvement: I don't have to re-establish the focus on the track to be moved before undoing.
Furthermore, I can plan the arranging and send the tracks in reversed order to top or bottom.