Audacity Forum

Paul L wrote:As for resuming TAB key navigation, consider the case of multiple label tracks. Present behavior is that each track defines a separate cycle of TAB order, which is reasonable. If TAB will also return me to navigating labels from focus in an audio track, which cycle should I enter?

There is only one cycle of labels that TAB or SHIFT + TAB can navigate through, and that is the label track that has focus.

If you are working through label track 2, TAB or SHIFT + TAB keeps you in the same label track.

If you want to switch to play labels in label track 1 or 3, use UP or DOWN arrow to move focus into that label track.


Gale

Gale Andrews wrote:

Paul L wrote:As for resuming TAB key navigation, consider the case of multiple label tracks. Present behavior is that each track defines a separate cycle of TAB order, which is reasonable. If TAB will also return me to navigating labels from focus in an audio track, which cycle should I enter?

There is only one cycle of labels that TAB or SHIFT + TAB can navigate through, and that is the label track that has focus.

If you are working through label track 2, TAB or SHIFT + TAB keeps you in the same label track.

If you want to switch to play labels in label track 1 or 3, use UP or DOWN arrow to move focus into that label track.


Gale

I understand that you described present behavior, but I was proposing new behavior. If TAB will resume label navigation when no label track is focused, as has been proposed, then I suggest you go to the nearest label in the last focused label track (if it has not been deleted), rather than to the nearest of all labels.

Paul L wrote:

Gale Andrews wrote:

Paul L wrote:As for resuming TAB key navigation, consider the case of multiple label tracks. Present behavior is that each track defines a separate cycle of TAB order, which is reasonable. If TAB will also return me to navigating labels from focus in an audio track, which cycle should I enter?

There is only one cycle of labels that TAB or SHIFT + TAB can navigate through, and that is the label track that has focus.

If you are working through label track 2, TAB or SHIFT + TAB keeps you in the same label track.

If you want to switch to play labels in label track 1 or 3, use UP or DOWN arrow to move focus into that label track.


Gale

I understand that you described present behavior, but I was proposing new behavior. If TAB will resume label navigation when no label track is focused, as has been proposed, then I suggest you go to the nearest label in the last focused label track (if it has not been deleted), rather than to the nearest of all labels.

I'm did not propose or support those ideas for the reasons stated, so I was explaining how the feature works (I think conveniently and logically) now. Your idea still seems impractical and confusing to me (especially for visually impaired users).

What do we do if the last focused label track does not exist? What do we do if user moved the last focused label track up or down? Should we also perform other actions in the label track when it lacks focus?

Why did you move the focus out of the label track if you were working on the labels? If it was because you wanted to play the label's audio, then won't the other changes proposed here help?

If you were applying an effect to the label's audio, I can see that moves the focus into the audio track. This seems reasonable, because it lets you use SPACE to play the audio while the label is still open for editing. Whether the label is open or not, I agree that TAB or SHIFT + TAB do nothing in that scenario.

TAB could in that scenario move the focus to the next label track down in order to open the nearest label for editing in that track (assuming TAB still does "open" rather than only "select"). TAB would not be able to move two label tracks down or one label track up.

What is the objection to using ARROW as intended, instead of muddying what TAB does?


Gale

Just passing on another idea for right-click that the [email protected] correspondent is keen on, which is "Export Labeled Audio". I'm not totally convinced, but it could tie in with right-click over an audio selection > "Export Audio".


Gale

Gale Andrews wrote: What do we do if the last focused label track does not exist? What do we do if user moved the last focused label track up or down? Should we also perform other actions in the label track when it lacks focus?

I leave it unspecified what happens when the label track has been deleted. Take me to some label, either first, or closest, in some label track. I don't see why vertical repositioning would matter though. The TAB cycle you were last in, still exists.

I do not understand how I propose to "perform actions in the label track when it lacks focus." I am just suggesting a navigation back to the track, no change in the tracks' contents.

Why did you move the focus out of the label track if you were working on the labels? If it was because you wanted to play the label's audio, then won't the other changes proposed here help?

Yes, my main complaint is that it's not easy to go through a sequence of labels and listen to each without using the mouse, and I'd take your compromise of distinguishing a CTRL-TAB cycling, which would not lose your position if you hit return and then space or shift-space or play-at-speed or other such command.

If you were applying an effect to the label's audio, I can see that moves the focus into the audio track. This seems reasonable, because it lets you use SPACE to play the audio while the label is still open for editing.

Are you describing present or hypothetical behavior now? I do not observe such behavior. When the label has a text cursor, SPACE puts a space there, it doesn't play.

Whether the label is open or not, I agree that TAB or SHIFT + TAB do nothing in that scenario.

I don't agree.

What is the objection to using ARROW as intended, instead of muddying what TAB does?
Gale

This, I don't understand. TAB and Shift-TAB have no effect when the focus is in an audio track. Why is it "muddying" to assign them one? (But maybe someone thinks they should select the clips of a track in sequence... which would make some kind of sense too). But give me the CTRL-TAB distinction and I won't insist strongly.

Are arrow keys supposed to take me back from listening to the audio to editing the label text now? They don't.

I think this all comes down to a lack of a distinction of two selection states for labels. I want them selectable either for text editing, or for purposes of playing (and perhaps also modifying, with effects) the corresponding audio in other highlighted tracks. Is anything wrong with that suggestion? As things are now I can't play the audio without de-selection of the label.

Here is another nuisance. If I click in the audio track outside of any label, then it seems any un-modified key like R causes creation of a new label with that character for text, regardless of the binding in editing preferences. I really dislike this. If I really want a label, I'll hit ctrl-b first. I'd like to change my preferences freely (I like 1, 2, 3 instead of ctrl1, ctrl-2, ctrl-3, for instance) and I want my shortcuts to keep their meanings even in label tracks unless I explicitly open a new or existing label for text editing.

And it seems special exceptions are made for the j and k and space keys, which don't create labels but change the cursor as normally. But then, try to edit a label, and enter j or k in the text -- and you DON'T get what you want, you still get the cursor jump! But space does what is right with a text cursor. The design seems disunified.

I think that you've raised some good points Paul, though obviously the developers need to weigh up the interests of all users, and not everyone will be happy with everything (you can't please all the people all the time

I agree that we could do with improvements to selecting labels and moving between labels.
I don't think that playing the audio marked by a label is, in itself, a problem - if the label is selected you just need to press Space, or if it is selected and open for editing, then it's just Enter -> Space. The problem as I see it is that once the audio has been played, the user has in effect been kicked out of the label and there's no convenient way back in, so I think this is just an extension of the same label navigation problem.

Paul L wrote:Here is another nuisance. If I click in the audio track outside of any label, then it seems any un-modified key like R causes creation of a new label with that character for text,

That's a popular feature with a lot of users. It makes creating labels very quick and easy, which is important for some users (for example when transcribing).

Paul L wrote:And it seems special exceptions are made for the j and k and space keys,

The space key is a special case.
The J and K keys are bugs - they are supposed to start labels like the other characters.

steve wrote:if the label is selected you just need to press Space, or if it is selected and open for editing, then it's just Enter -> Space.

What do you mean by "or?" There seems only one selected-label state, that is the one with a text cursor, that is what you get by picking on the box. It's always Enter, Space after that to hear the selection, it is never just Space, which always puts a space in the label text. Unless I am overlooking something.

Paul L wrote:Here is another nuisance. If I click in the audio track outside of any label, then it seems any un-modified key like R causes creation of a new label with that character for text,

That's a popular feature with a lot of users. It makes creating labels very quick and easy, which is important for some users (for example when transcribing).

I think it is redundant with ctrl-b and I dislike it. To "please everybody" in this case, there could be an editing preference governing this behavior.

Paul L wrote:And it seems special exceptions are made for the j and k and space keys,

The space key is a special case.
The J and K keys are bugs - they are supposed to start labels like the other characters.

Not only do j and k have their shortcut behavior when the focus is in the label track (which I do like, as I said I'd rather have ALL shortcuts work that way), the bug is that they ALSO have that behavior whenever you are at a text cursor. It seems I can't make a label containing j or k in its text.

Paul L wrote:What do you mean by "or?" There seems only one selected-label state

I mean, if you click in a label text area, the label is "selected" and "open for text editing". If you press "Enter", the the label is still "selected" but is not open for text editing.

Paul L wrote:It seems I can't make a label containing j or k in its text.

The release note suggests a workaround for if you can't enter J or K in a label: "In many cases, Edit > Undo then Edit > Redo will allow you to type in the label."
This bug does not affect everyone - I can't reproduce the problem on my machine.

Paul L wrote:I'd take your compromise of distinguishing a CTRL-TAB cycling, which would not lose your position if you hit return and then space or shift-space or play-at-speed or other such command.

OK.

Paul L wrote:

Gale Andrews wrote:If you were applying an effect to the label's audio, I can see that moves the focus into the audio track. This seems reasonable, because it lets you use SPACE to play the audio while the label is still open for editing.

Are you describing present or hypothetical behavior now? I do not observe such behavior. When the label has a text cursor, SPACE puts a space there, it doesn't play.

Actually, current behaviour.

1. Click in a label to open it (focus is in the label track)
2. For example, type ALT, then type C, then type A to open Amplify, then ENTER to amplify to 0 dB (focus moves to audio track)
3. SPACE to play the track (while the label is open for editing)
4. DOWN arrow and type in the label "Amplified to 0 dB".

Paul L wrote:

Gale Andrews wrote: Whether the label is open or not, I agree that TAB or SHIFT + TAB do nothing in that scenario.

I don't agree.

Actually I meant in the sense "I concur with your finding that TAB or SHIFT + TAB do nothing while focus is in the audio track. I don't mind them doing something predictable (and understandable to the visually impaired), but I don't see very clear options. Letting TAB or SHIFT + TAB move into a label in the next label track underneath the audio track is predictable, and probably useful in many cases, but I would guess it might not be seen as very "pure" to complicate its currently very clear purpose.

Paul L wrote:

Gale Andrews wrote:What is the objection to using ARROW as intended, instead of muddying what TAB does?

This, I don't understand. TAB and Shift-TAB have no effect when the focus is in an audio track. Why is it "muddying" to assign them one? (But maybe someone thinks they should select the clips of a track in sequence... which would make some kind of sense too).

That's an idea that's worth recording, I think. It could be thought "purer" than moving focus into the label track because it retains the original purpose (navigation in the focused track).

Paul L wrote:Are arrow keys supposed to take me back from listening to the audio to editing the label text now? They don't.

UP arrow moves focus to the track above (whatever type of track it is) and DOWN arrow moves focus to the track below (whatever type of track it is).

In the example above where an effect forces focus back into the audio track and the label remains open for editing, then UP arrow and DOWN arrow do take you from listening to editing the audio.

I've argued before that if the label is open for editing, with focus in the label track, that UP arrow into an audio track should close the label. As it is now, you have to close the label with ENTER before you can even use UP.

However in some use cases (transcription) you may want UP to leave the label open, in which case you can UP and SPACE to play, DOWN and type to type in the label. Do you want to vote for either of those ideas for what UP should do in the case where the label is already open?

I''m beginning to think letting UP leave the label open could be more useful, not confusing, and possibly "purer". To reinforce that, if you are forced to close the label when you wanted to carry on editing, it is not easy to open it again with the keyboard. Hence the suggestion about a special shortcut to open a selected, closed label, or (my preferred solution) let TAB or SHIFT + TAB do that.

Paul L wrote:Here is another nuisance. If I click in the audio track outside of any label, then it seems any un-modified key like R causes creation of a new label with that character for text,

steve wrote:That's a popular feature with a lot of users. It makes creating labels very quick and easy, which is important for some users (for example when transcribing).

I think it is redundant with ctrl-b and I dislike it. To "please everybody" in this case, there could be an editing preference governing this behavior.

I'll add your vote for that one. You can never be able in all cases to type in the label track without using a shortcut AND use single-key/typable shortcuts to perform an action while the label track has focus. We've put a lot of effort into making it work but there are inevitable compromises (and bugs open for it, besides the "J" and "K" problem).

steve wrote:If you click in a label text area, the label is "selected" and "open for text editing". If you press "Enter", the the label is still "selected" but is not open for text editing.

If we can make it easier to select a label without opening it for editing, this distinction should be clearer.



Gale