Audacity Forum

I think the stop button should be inferred when clicking on certain editing features (like cut / copy, etc.) - it would be more efficient during intensive editing to assume we want to click the stop button when we click the cut button...

Audacity rules! Thanks for putting out such a great product.

This has been discussed quite recently by the developers, and generally I think it is a good idea.

"Stop" will stop both playback and recording. I don't see any major problems with inferring "stop" if an edit command is selected during playback, and I think it would save a lot of new user problems if stop was inferred when playback is paused (it is quite common for new users to be confused that effects are not available while playback is paused). I don't think that stop should be inferred during recording. In my opinion it is already too easy to inadvertently abort a recording (which could be a once in a lifetime, never to be repeated, live event).
So if you mean stopping playback only (including paused playback, but not stopping a recording), then I'm +1 for this proposal.

When audio is selected and an edit command is invoked:

+1 for Stop to be inferred when paused

-0 for Stop to be inferred during Playback

-1 for Stop to be inferred during recording

And I'm thinking that this should only apply if the user has made an explicit selection - rather than an implied "Select All" by having Preferences>Tracks>Selected all audio in project, if none selected is checked "on".

Peter

[moderator note: topic split to: http://forum.audacityteam.org/viewtopic ... 53#p263753]

A significant question is where we auto-stop on choosing an edit command - where playback started from or where it ended? I have not seen the discussion, so what was the decision about that?

If Pause is allowed to autostop at the pause point, it may be OK for Play to autostop where playback started, though there are bound to be two camps about it.


Gale

Gale Andrews wrote:We should have a Bugzilla issue and Wiki page for this I think.

Probably a good idea Gale, just to keep some focus on it. Do you want me to try to find some time to kick that off?

After our discussion at AU14, Leland was all set to implement this - but somehow he got "sidetracked" on a ton of other issues

steve wrote:The discussion was at AU14 and was about the specific case of paused playback (a frequent cause of confusion for new users).

And not just the new users, it still catches me out from time to time

That's why I was keen to discuss it with Leland at AU14

Note that I've modified my thinking and voting in my earlier post on thinking about this some more. It's a great idea when the user is in pause mode, I'm not so convinced when playback is in use - and I agree with Steve that it definitely should not be allowed to interrupt a recording.

Peter.

Gale Andrews wrote:

waxcylinder wrote:

Gale Andrews wrote:We should have a Bugzilla issue and Wiki page for this I think.

Probably a good idea Gale, just to keep some focus on it. Do you want me to try to find some time to kick that off?

If you have time, please do. I think whether this works with editing shortcuts and where the cursor sets down when you call an edit during play (or if it works during play at all) should be discussed.

Obviously if you call an edit during pause we should do stop and set cursor.

I just started work on a draft proposal and then pulled myself up short as I am now unsure about the scope.

The original poster wanted an "inferred Stop" if an Edit command was issued in Pause mode.

My memory of the discussion with Leland at AU14 was an "inferred stop" followed by action when an Effect command was issued when in Pause mode.

In making this proposal do we want to broaden it and extend it to other commands issued when in Pause mode such as File, Transport, Tracks, Analyze, Generate, i.e. all of the commands that are grayed out while in Pause mode?

With this breadth of scope the proposal could be as simple as "Proposal Inferred Stop when command issued in Pause mode" - but I suspect it wouldn't turn out as simple as that.

Alternative idea
==============
One of the reasons that users are confused, when in pause mode and try to do stuff, is that the only visual cue is the grayed out commands and they don't understand what the graying-out means. The problem is worse if the user issues a keyboard shortcut for an inoperable command when in pause mode as all Audacity does then is just sit there.

Long ago I made the suggestion that when a user tried to issue an inoperable command while in pause mode (either via a grayed-out command or via a shortcut) - then Audacity should simply pop up an error message saying something like "Can't do this while Paused, Press the Stop button and try again".

This seems to me to be a very simple, straightforward and clear solution. It doesn't involve any state changes by inference - it avoids us having to think about cursor location on completion. I like it as it "reminds" the user to use the Stop button.

As I recall more fully my discussion with Leland at AU14 it was along the lines of "Leland, how easy would it be for you to implement an error message when the user wants to do something when paused rather than stopped"?" .
He pondered that for a moment ad replied with something like "Hell no, what if I just fixed it so it actually just did the something ... "
Steve and I looked at each other and said "That might work ..."


Conflated idea
=============
We could even conflate the two approaches by popping up a dialog rather that a simple error message:

"You are only Paused, do you want to Stop and <action> Y/N"

But personally I think this is a poor option - and we know the TLC like to avoid "nag dialogs" as far as possible.

Peter.

This'll make you laugh ...

Having set up a project for testing which I left with a couple of trivial tracks in pause mode - I then go back to it and try, and try, to delete the two tracks via their top-left X.

The set me pondering for a while till I remembered I was only Paused ...

waxcylinder wrote:My memory of the discussion with Leland at AU14 was an "inferred stop" followed by action when an Effect command was issued when in Pause mode.

OK but now we have RTP effects and will make all effect classes RTP, the inferred stop for those won't make a big difference. The effect will open anyway assuming a track is selected. We would save applying Stop in the effect, but if the user just applied the effect without preview, the RTP effect stops playback or paused playback on apply already.

waxcylinder wrote:In making this proposal do we want to broaden it and extend it to other commands issued when in Pause mode such as File, Transport, Tracks, Analyze, Generate, i.e. all of the commands that are grayed out while in Pause mode?

With this breadth of scope the proposal could be as simple as "Proposal Inferred Stop when command issued in Pause mode" - but I suspect it wouldn't turn out as simple as that.

I think so, but it would also be a great time saver to be able to start playing a selection, realise that is the bit you want, then click Copy, Cut, Trim or whatever it is.

Then those Edit Toolbar buttons which are currently falsely enabled when playing or paused would actually not need to be grayed. They would stop playback and perform the operation requested.

waxcylinder wrote:Alternative idea
==============
One of the reasons that users are confused, when in pause mode and try to do stuff, is that the only visual cue is the grayed out commands and they don't understand what the graying-out means. The problem is worse if the user issues a keyboard shortcut for an inoperable command when in pause mode as all Audacity does then is just sit there.

Long ago I made the suggestion that when a user tried to issue an inoperable command while in pause mode (either via a grayed-out command or via a shortcut) - then Audacity should simply pop up an error message saying something like "Can't do this while Paused, Press the Stop button and try again".

This seems to me to be a very simple, straightforward and clear solution. It doesn't involve any state changes by inference - it avoids us having to think about cursor location on completion. I like it as it "reminds" the user to use the Stop button.

As I recall more fully my discussion with Leland at AU14 it was along the lines of "Leland, how easy would it be for you to implement an error message when the user wants to do something when paused rather than stopped"?" .
He pondered that for a moment ad replied with something like "Hell no, what if I just fixed it so it actually just did the something ... "
Steve and I looked at each other and said "That might work ..."

I prefer just to do the something, I must say.


Gale