Audacity Forum

waxcylinder wrote:Let's remember the reason for starting this thread - it wasn't about the ability to do "stuff" while paused (how many folk actually want/need to do that?) - it was about helping hapless folk like the thread linked to in the initial post who can't figure out why "stuff" doesn't work (including me occasionally)

but if Pause did not lock the user out from editing (with no obvious reason why) then the problem would not exist and would not need solving. Editing while paused is, as far as I can see, only disabled due to a technical issue, not because it is helpful for users. Better imho to solve the technical issue.

Gale Andrews wrote:

steve wrote:Would it be beneficial if "Stop" when paused left the playback cursor in the current position rather than returning it to the previous playback position?

I think it may take some getting used to if you really wanted to go back to the previous playback position,

If the user wanted to stop and go back to the original play position, why did they press the Pause button? Surely the fact that the user pressed the Pause button indicates that they want to be at the current position?

Gale Andrews wrote:and would only address a subset of the problem.

There's nothing wrong with addressing a subset of the problem is there?

Gale Andrews wrote:I think there is a strong case for our Stop and Set Cursor to be a Transport Toolbar button

That only addresses a subset of the problem but yes I agree that there is a case. Although such a proposal is related to the feature request that is the subject of this topic, it's really a different proposal and I think deserves its own topic (which could also look at the behaviour of the other transport toolbar buttons).

steve wrote:If a function is greyed out, then there is no "on click" action, so where is the opportunity to notify the user?

A ToolTip, obviously.

steve wrote:The tools are greyed out because they are not available for use.
Greying out provides an instant visual indication if a particular function is available or not

steve, I don't mean to be insulting, but if I was running a software company and had you on the GUI design team, you'd be either off of it or fired based on that remark.

It makes perfect sense to a programmer that a button which is greyed out can't be clicked on. But grandma doesn't know that! Users are idiots! You know this in advance and can consciously plan for that fact.

I really think it ought to be a general rule that any program that has greyed out GUI elements should come with ToolTips or other GUI features that provide some explanation as to why the elements are unavailable. (ex: "You can't apply effects while paused. Try pressing stop.")

I just pushed play then pause and as far as I can see there are no GUI elements (other than menu items) which are disabled just because of the pause mode. In fact there are some GUI elements (toolbar buttons) which should be disabled and are not (e.g. envelope tool). To the best of my knowledge there is no way to provide a tooltip for a menu item. While I firmly agree that it would be nice to offer some feedback as to why the menu items are grayed out I really see only one method of doing so - and it is ugly.

As I see it the only possible way to provide this feedback is to throw up a dialog when the pause button is clicked warning the user that grayed-out items are unavailable due to the pause mode and give it the "don't show this again" checkbox and appropriate preference entry to turn it on/off - ugly.

It's also my belief that this is unnecessary. Only a person who is completely new to computer use will find the convention of graying out of the menu items when unavailable confusing. Audacity is way too sophisticated for that user. There are three kinds of people using Audacity: 1) those who read the manual, 2) those who fumble about and learn from experience and 3) those who ask questions when confused. Types 1 & 3 are probably not staying confused for too long; type 2 has made a conscious decision to do it the hard way - we cannot hold their hand.

Nerd42 wrote:steve, I don't mean to be insulting, but if I was running a software company and had you on the GUI design team, you'd be either off of it or fired based on that remark.

No offence taken - in that hypothetical situation I'd resign after successfully suing your pants off for wrongful dismissal
Have you ever seen any program anywhere that gives ToolTips on sub-menu items? I'm not a programmer but I don't think that wxWidgets provides that feature, presumably because no-one ever does that. Greying out menu items is supported by wxWidgets and is a very well established convention that is familiar to everyone that has used a computer for more than a couple of days. Audacity aims to be usable without requiring specialist knowledge of audio software, but it cannot hope to be fully accessible to users that have absolutely no knowledge of computer software. For such users even Sound Recorder will be too complicated. ToolTips are widely used by Audacity for graphical interface items, though a complete novice to computers will probably not be aware of them until they accidentally hover the mouse over an item for long enough for the ToolTip to appear. Grandma may not know that the on screen pointer can be moved with the mouse - hopefully one of her grandchildren will help her to get started.

Edgar wrote:As I see it the only possible way to provide this feedback is to throw up a dialog when the pause button is clicked warning the user that grayed-out items are unavailable due to the pause mode and give it the "don't show this again" checkbox and appropriate preference entry to turn it on/off - ugly.

Yes, ugly and imho an unnecessary annoyance.

From user feedback on this forum there is clearly a problem that some (many) users do not realise that most features are disabled because Audacity is paused. I don't think there has been even one person that did not realise that the greyed out items were disabled (though that may be because they don't know how to post to a forum or send an e-mail to the feedback address). The problem is that they don't know why the items are greyed out (and I agree that it is not obvious why "pause" should disable editing and effects). As I wrote previously, I think that the most useful and convenient solution would be to grey out menu items only during record, and to automatically apply "stop" when using an effect while paused. Users may still complain that they want to be able to edit while playing/recording (not currently possible) but at least the behaviour would be discoverable,

steve wrote:Would it be beneficial if "Stop" when paused left the playback cursor in the current position rather than returning it to the previous playback position?

If the user wanted to stop and go back to the original play position, why did they press the Pause button? Surely the fact that the user pressed the Pause button indicates that they want to be at the current position?

Yes but it doesn't indicate they want to stay there there when they press Stop. You are suggesting a conditional behaviour for the Stop button rather than having it do one understood thing.

For example (probably common) you may want to Play, Pause, CTRL + M to annotate the pause position (or select then CTRL + B to annotate a region just heard) then press Pause to continue and so on. Then you want to play through all the audio you have labelled from where you started. Even if Stop did do Stop and Set Cursor when in paused state, I agree the user could just hit Play to do what they want. But I bet not many know that.

If there was a separate Stop and Set Cursor button, user can choose where to set the cursor on stop (whether they are paused or not), and each Stop button performs an absolute command rather than a conditional one. The new button would be obvious to existing users so they would find it easily.

Additionally in my example, a Stop and Set Cursor button provides an easier way to avoid typing a new label containing "A" that you don't want.

I don't think yours is a bad idea - maybe even more people would want it than not - but not everyone would, and a new button seems to kill both aspects of this part of the problem.

steve wrote:As I wrote previously, I think that the most useful and convenient solution would be to grey out menu items only during record, and to automatically apply "stop" when using an effect while paused. Users may still complain that they want to be able to edit while playing/recording (not currently possible) but at least the behaviour would be discoverable

Really very few people ask for editing while recording but I would still argue that some edits while playing may seem very intuitive on the face of it.

If we apply Stop when using an effect while paused, I would expect it to be just as simple to apply Stop when playing (forcing a Stop when recording would not be desirable).

If the menu items are active when playing, what are you proposing should happen when user selects something they just heard then without clicking Pause or Stop, clicks an active Edit > Remove Audio or Labels > Silence Audio item?


Gale

Gale Andrews wrote:You are suggesting a conditional behaviour for the Stop button rather than having it do one understood thing.

The behaviour is conditional whichever way you do it:

Current behaviour:
If playback is stopped while Paused (condition)
then stop and return cursor to previous play-from position.

Proposed behaviour:
If playback is stopped while Paused (condition)
then stop.

Gale Andrews wrote:If there was a separate Stop and Set Cursor button, user can choose where to set the cursor on stop (whether they are paused or not), and each Stop button performs an absolute command rather than a conditional one.

A "Stop and Set Cursor" would be a lot more convenient and discoverable than Shift+A.
What do you think it should look like? Could you make a mock-up?

Gale Andrews wrote:If we apply Stop when using an effect while paused, I would expect it to be just as simple to apply Stop when playing

I agree, that should be possible, but I think there is one other potential problem....

Gale Andrews wrote:If the menu items are active when playing, what are you proposing should happen when user selects something they just heard then without clicking Pause or Stop, clicks.....

I don't see that to be the problem - the edit/process would be applied to the selected region.
I think that the "potential problem" is: What if the user has not selected a region but selects an edit/effect during play. What should happen in that case?

steve wrote:

Gale Andrews wrote:You are suggesting a conditional behaviour for the Stop button rather than having it do one understood thing.

The behaviour is conditional whichever way you do it:

Current behaviour:
If playback is stopped while Paused (condition)
then stop and return cursor to previous play-from position.

Proposed behaviour:
If playback is stopped while Paused (condition)
then stop.

Programmer's perspective?

A user may only be looking at the buttons. If "Stop" only returns to the original cursor position and "Stop and Set Cursor" only sets the cursor at (roughly) the audio position, then each button has no conditional - it always does the same.

There is another possibility for Stop behaviour after Pause which Wavosaur shows. If you play, pause, then stop, it stops and sets cursor at the stop point (like you suggested). But if you play, pause, pause again (to resume play) then stop, it stops and sets cursor at the point where playback last paused. I'm not sure I like that either, for the same reasons, but either of those could perhaps be a specialised preference, only available if you use the audacity.cfg editor we talked about.

Or if we had a separate Stop and Set Cursor button, that could be one Transport Toolbar set and another set could be the current single Stop button layout, which behaves as Wavosaur's Stop button does (with no choice about the behaviour).

steve wrote:A "Stop and Set Cursor" would be a lot more convenient and discoverable than Shift+A.

When you examine it there weren't many other good choices that work on all keyboards and all OS'es.

CTRL and SPACE would have been good, except Mac uses it to open the "Spotlight" search in the Audacity Help menu.

steve wrote:What do you think it should look like? Could you make a mock-up?

I could see it being either the same yellow rectangle as now containing a black (?) downward-pointing arrow.

In that case, perhaps the current Stop would have a black (single) left-pointing arrow.

Or perhaps Stop and Set Cursor would be a yellow downward-pointing triangle. And Stop (if changed) would be a single left-pointing arrow.

steve wrote:

Gale Andrews wrote:If the menu items are active when playing, what are you proposing should happen when user selects something they just heard then without clicking Pause or Stop, clicks.....

I don't see that to be the problem - the edit/process would be applied to the selected region.

I think that the "potential problem" is: What if the user has not selected a region but selects an edit/effect during play. What should happen in that case?

Advanced users might have unchecked "Select All... if none selected" in Tracks Preferences in which case I assume that with the audio playing or paused and no selection, the menu items that depend on selection would remain greyed. I therefore assume that CTRL + I would in the absence of a selection be enabled and perform Stop, then split at the cursor.

With "Select All... if none" checked (as it is by default), then menu items that depend on selection would unless we changed it remain enabled when audio is busy and so after Stop, would select all the project audio if an effect or region edit was asked for.

I've known more than a few people thinking that selecting an effect during playback with no region present should pause (or stop), open the effect but still let them drag a selection starting at the place the audio stopped, and then apply the effect.

So in the absence of effects that let you select audio while they are open, there may be a fringe case. Choosing an effect or edit while the audio is busy but there is no selection would stop and set cursor at the stop position (like you suggested manual stop when paused should do), rather than stop, select all then open the effect. I doubt that should be more than an optional preference, though.


Gale

Gale Andrews wrote:A user may only be looking at the buttons. If "Stop" only returns to the original cursor position and "Stop and Set Cursor" only sets the cursor at (roughly) the audio position, then each button has no conditional - it always does the same.

The buttons look much like the buttons on a tape recorder. On a tape recorder the Stop button just stops playback, it doesn't usually stop and rewind, so I think that it is a reasonable argument that "stop here" (stop and set cursor) could be considered the normal behaviour and "stop and return" considered the alternative behaviour.

Two ways of looking at "stop on pause":
1) The "original playback position" is the position when "Play" was pressed.
2) The "original playback position" is the position when "Pause" was pressed.
In other words, when Pause is pressed, does/should that be considered to be the last playback position, or should the last playback position depend only on when the Play button is pressed? - I think that can be argued either way.

Gale Andrews wrote:When you examine it there weren't many other good choices that work on all keyboards and all OS'es.

I wasn't criticising the choice of keys, just commenting that a keyboard combination is much less discoverable than a button.

Gale Andrews wrote: I could see it being either the same yellow rectangle as now containing a black (?) downward-pointing arrow.

In that case, perhaps the current Stop would have a black (single) left-pointing arrow.

How about a chevron rather than an arrow?

Gale Andrews wrote:I've known more than a few people thinking that selecting an effect during playback with no region present should pause (or stop), open the effect but still let them drag a selection starting at the place the audio stopped, and then apply the effect.

The case for that becomes much weaker if we have a "Stop Here" (stop and set cursor) button.

steve wrote: The buttons look much like the buttons on a tape recorder. On a tape recorder the Stop button just stops playback, it doesn't usually stop and rewind, so I think that it is a reasonable argument that "stop here" (stop and set cursor) could be considered the normal behaviour and "stop and return" considered the alternative behaviour.

+1 for it working like my tape deck and my old VCR

It always annoys the hell out of me when it whazzes back

Peter

waxcylinder wrote:+1 for it working like my tape deck and my old VCR

Note that I am not suggesting that we change the current default behaviour. I'm agreeing with Gale that it would be useful to have both behaviours (two buttons); "Stop Here" (stop and set cursor) and "Stop and Rewind" (the current Stop button).

On first thought I like the idea of alternative Transport Toolbars. Which would be the default?