Difference between revisions of "Completed Proposal Action edits when in Pause mode"

From Audacity Wiki
Jump to: navigation, search
(Record continues on same track....)
m (Text replace - "http://bugzilla.audacityteam.org" to "https://bugzilla.audacityteam.org")
 
(22 intermediate revisions by 3 users not shown)
Line 2: Line 2:
  
 
__NOTOC__
 
__NOTOC__
{{alert|'''This proposal is not intended to be tackled until after 2.1.0 release.'''<p>This does not preclude earlier discussion of how it might be tackled </p> }}
+
 
 +
 
 
==The Problem==
 
==The Problem==
 
It is reported at least once or twice a week that new users are confused that editing and effects functions are not available while playback is paused.  Even experienced users can be caught out by this, forgetting they are paused rather than stopped and then pondering why the effects don't work.   
 
It is reported at least once or twice a week that new users are confused that editing and effects functions are not available while playback is paused.  Even experienced users can be caught out by this, forgetting they are paused rather than stopped and then pondering why the effects don't work.   
Line 10: Line 11:
 
Many users report that they don't understand why their commands are grayed-out.  The problem is worse when the user is paused and tries to use a keyboard shortcut to effect a command as in those circumstances Audacity does precisely nothing with no visual cue at all.
 
Many users report that they don't understand why their commands are grayed-out.  The problem is worse when the user is paused and tries to use a keyboard shortcut to effect a command as in those circumstances Audacity does precisely nothing with no visual cue at all.
  
[http://bugzilla.audacityteam.org/show_bug.cgi?id=1205 Bug#1205] has been raised to track this issue.
+
The problem we need to address is not just the ability to use effects when the user has pressed Pause, but also other commands like Export, Save, Import and anthing else the user wants to do with Audacity but is blocked by the Pause state.
 +
 
 +
[https://bugzilla.audacityteam.org/show_bug.cgi?id=1205 Bug#1205] has been raised to track this issue.
  
 
== Proposed Feature ==
 
== Proposed Feature ==
 
There are several solutions to this problem that have been proposed:
 
There are several solutions to this problem that have been proposed:
  
1) <strike>'''Error Message''' - Peter proposed this a while back in a Forum discussion </strike>
+
1) '''Error Message''' - Peter proposed this a while back in a Forum discussion  
 +
 
 +
2) '''Pause behaves like Stop''' - Proposed by James 08Jan15.  (In AU14 TrackPanel I don't have a pause button, because Pause and Stop would do exactly the same).
  
2) '''Pause behaves like Stop''' - Proposed by James 08Jan15:
+
3) '''Stop and Do''' - (Inferred Stop when Paused) Suggested by Leland at AU14 in discussion with Peter & Steve
  
3) '''Inferred Stop when Paused''' - Suggested by Leland at AU14 in discussion with Peter & Steve
+
==Solution==
 +
For 2.1.3 James implemented what is effectivley the "'''Stop and Do''' - (Inferred Stop when Paused)" proposed by Leland at AU14.
  
 
==Developer/QA Backing==
 
==Developer/QA Backing==
* Gale is in favor of retaining Pause (unless proved unwanted), adding a Stop and Set Cursor button, and "stop and do the requested action" when there is active or paused playback. Active playback stops at the start position and paused playback stops where playback stops. Ideally I would like paused playback resumed after the effect or edit.  
+
* If we don't want the work of keeping the stream open, Gale is in favor of retaining the Pause button, adding a Stop and Set Cursor button, and on user pausing and performing a forbidden action, we stop, release Pause button and set the cursor at the point we stopped. After the action completes, monitoring resumes and the pause button re-engages itself.
* James is in favor of eliminating the pause button.  That's how it works in the new track panel.
+
* James also strongly supports Stop-and-Do as a solution, since conservative folks that we are, we likely want to retain the pause button.  Stop-and-Do is a good solution to our current stuck-in-pause.
* Peter - I support Leland's proposal
+
* Peter - I support Leland's proposal - Option 3 "Stop and do" - if we cannot do that then Option-1 would be a good interim solution.
 
 
  
 
==Use Cases==
 
==Use Cases==
Line 34: Line 39:
 
==Details==
 
==Details==
  
<strike>
 
 
=== 1) Error Message ===
 
=== 1) Error Message ===
 
*when a user tries 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'''".  Just a simple {{button|OK}} button to dismiss the message.  No "'''Do not show this message again'''" checkbox.  No {{button|Continue}} button to go ahead and effect the command.
 
*when a user tries 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'''".  Just a simple {{button|OK}} button to dismiss the message.  No "'''Do not show this message again'''" checkbox.  No {{button|Continue}} button to go ahead and effect the command.
 
*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.
 
*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.
 
*logically if we do this, we should do much the same for commands grayed out because no selection has been made.  
 
*logically if we do this, we should do much the same for commands grayed out because no selection has been made.  
</strike>
 
  
 
=== 2) Pause behaves like Stop ===
 
=== 2) Pause behaves like Stop ===
Line 48: Line 51:
 
** '''Gale 21Jan15:''' The above is basically what I am now supporting at the bottom of the [[Talk:Proposal_Action_edits_when_in_Pause_mode#Eliminating_the_pause_button|Talk Page]], providing "resume" is fixed to be quick and glitchless, and providing Stop goes back to where the  cursor started.     
 
** '''Gale 21Jan15:''' The above is basically what I am now supporting at the bottom of the [[Talk:Proposal_Action_edits_when_in_Pause_mode#Eliminating_the_pause_button|Talk Page]], providing "resume" is fixed to be quick and glitchless, and providing Stop goes back to where the  cursor started.     
  
=== 3) Inferred Stop when Paused - "stop and do" ===
+
=== 3) Stop and Do - (Inferred Stop when Paused) ===
 
*Leland had previously suggested a "stop and do" ''(in a discussion with Peter & Steve at AU14 in response to Option-1)'' that when Pause was enabled and an Edit command issued we could automatically stop transport and perform whatever action was requested.
 
*Leland had previously suggested a "stop and do" ''(in a discussion with Peter & Steve at AU14 in response to Option-1)'' that when Pause was enabled and an Edit command issued we could automatically stop transport and perform whatever action was requested.
*A "stop and do" should '''''not''''' be inferred and acted upon when Audacity is in Record mode (either paused or active).
+
*A "stop and do" should '''''not''''' be inferred and acted upon when Audacity is in active Record mode - but '''''should''''' be inferred and acted upon when the Recording is in Pause mode.
 +
*The Pause button should be popped up when the "stop and do" is acted upon - and after the "stop and do" Audcity will be in ready mode and not paused.
 
** '''Gale 05May15:''' If user depressed Pause then we could do what Steve and I suggest above (stop the stream and set cursor at the stop position but leave Pause depressed). Edits would be available because we were already stopped. I assume pressing Pause might leave Record or Play depressed but Stop would be disabled  - but that would have to be discussed.
 
** '''Gale 05May15:''' If user depressed Pause then we could do what Steve and I suggest above (stop the stream and set cursor at the stop position but leave Pause depressed). Edits would be available because we were already stopped. I assume pressing Pause might leave Record or Play depressed but Stop would be disabled  - but that would have to be discussed.
 
 
=== 4) "Stop and Do+" ===
 
 
[Elaboration by James]
 
 
* The SHIFT-stop now does stop and set cursor.  (like SHIFT-A)
 
* Stop-and-do always uses shift-stop rather than just stop.
 
* At the moment if you use SHIFT-A to stop recording and then hit record again, it adds onto a NEW track.  We make this smarter so that it adds onto the same track, if there is space to the right (and the recording mode mono/stereo is the same).
 
 
Then we can do stop-and-do with Audacity in record-paused mode too, not just play-paused mode.  The issue I have with 3 is that it only solves it for play-paused.  "Stop and Do+" makes the inferred stop more like a pause, because the cursor is updated, and you can resume by clicking record or play (instead of the now popped up) pause.
 
 
* '''Gale: 03Jul16:''' 95% of the (reported) problem is pausing playback.  The Pause button is still needed, IMO. Users won't find SHIFT + A in the absence of a button, or SHIFT-Stop. <p> Why wouldn't Stop and Do work when pressing Pause during recording then choosing an edit or effect item? Having pressed Pause, the user has already interrupted the stream, whatever they actually intend. It's already obvious they intend to resume from the pause point (or playback stopped point, given we can't edit while paused).  </p>
 
* '''James: 03Jul16:''' Stop and Do during recording, IF equivalent to SHIFT-A, i.e. if using that code, would record on a new track when you click record again.  Whereas releasing pause continues on the same track.  So I am saying recording after Stop-and-do+ should not start a new track.  I am taking the formula in 3) in making it work for record too....
 
 
  
 
===GUI Examples===
 
===GUI Examples===

Latest revision as of 13:31, 21 August 2017

Proposal pages help us get from feature requests into actual plans. This page is a proposal to solve regular user confusion that they cannot interact with most action menus when paused (or playing).
Proposal pages are used on an ongoing basis by the Audacity development team and are open to edits from visitors to the wiki. They are a good way to get community feedback on a proposal.


  • Note: Proposals for Google Summer of Code projects are significantly different in structure, are submitted via Google's web app and may or may not have a corresponding proposal page.



The Problem

It is reported at least once or twice a week that new users are confused that editing and effects functions are not available while playback is paused. Even experienced users can be caught out by this, forgetting they are paused rather than stopped and then pondering why the effects don't work.

The confusion is understandable because the user can clearly make selections while in pause mode - they then expect to be able to act on those selections.

Many users report that they don't understand why their commands are grayed-out. The problem is worse when the user is paused and tries to use a keyboard shortcut to effect a command as in those circumstances Audacity does precisely nothing with no visual cue at all.

The problem we need to address is not just the ability to use effects when the user has pressed Pause, but also other commands like Export, Save, Import and anthing else the user wants to do with Audacity but is blocked by the Pause state.

Bug#1205 has been raised to track this issue.

Proposed Feature

There are several solutions to this problem that have been proposed:

1) Error Message - Peter proposed this a while back in a Forum discussion

2) Pause behaves like Stop - Proposed by James 08Jan15. (In AU14 TrackPanel I don't have a pause button, because Pause and Stop would do exactly the same).

3) Stop and Do - (Inferred Stop when Paused) Suggested by Leland at AU14 in discussion with Peter & Steve

Solution

For 2.1.3 James implemented what is effectivley the "Stop and Do - (Inferred Stop when Paused)" proposed by Leland at AU14.

Developer/QA Backing

  • If we don't want the work of keeping the stream open, Gale is in favor of retaining the Pause button, adding a Stop and Set Cursor button, and on user pausing and performing a forbidden action, we stop, release Pause button and set the cursor at the point we stopped. After the action completes, monitoring resumes and the pause button re-engages itself.
  • James also strongly supports Stop-and-Do as a solution, since conservative folks that we are, we likely want to retain the pause button. Stop-and-Do is a good solution to our current stuck-in-pause.
  • Peter - I support Leland's proposal - Option 3 "Stop and do" - if we cannot do that then Option-1 would be a good interim solution.

Use Cases

  • The visual cue of grayed-out commands while paused is not understood by users.
  • When in Pause mode, if a keyboard shortcut command is issued there is no visual cue or warning/error message.
  • When Audacity is in stasis mode, neither playing or recording, and the user issues a command it is clear that they expect that command to be executed.

Details

1) Error Message

  • when a user tries 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". Just a simple OK button to dismiss the message. No "Do not show this message again" checkbox. No Continue button to go ahead and effect the command.
  • 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.
  • logically if we do this, we should do much the same for commands grayed out because no selection has been made.

2) Pause behaves like Stop

  • Pause behaves exactly like stop, except that the play/record cursor is updated to be at the pause place.
    • Gale 09Jan15: Users can now access a real time preview (RTP) effect when playback is paused - they can apply the effect at once or stop and restart playback.

      The proposal means that Pause is no longer a Pause button that leaves transport open (e.g. "arms" a recording) but is a de facto Stop and Set Cursor button. If we remove Pause de facto or explicitly we need to be sure there is no use for paused transport and we need to be sure that those who want to stop and set cursor where it started from can still do so.

      • Steve 20Jan15: Testing with LADSPA effects, users can now access a real time preview (RTP) effect when playback is stopped - they can apply the effect at once or stop and restart playback.
    • Steve 20Jan15: I think that we would want to retain the current behaviour that "un-pausing" resumes play/record, which would mean that the "Pause" button would stop, set cursor, and remember whether it was playing or recording. Ideally that should work per project, but worth noting that the current "Pause" function is global (a current limitation of multi-project handling).
    • Gale 21Jan15: The above is basically what I am now supporting at the bottom of the Talk Page, providing "resume" is fixed to be quick and glitchless, and providing Stop goes back to where the cursor started.

3) Stop and Do - (Inferred Stop when Paused)

  • Leland had previously suggested a "stop and do" (in a discussion with Peter & Steve at AU14 in response to Option-1) that when Pause was enabled and an Edit command issued we could automatically stop transport and perform whatever action was requested.
  • A "stop and do" should not be inferred and acted upon when Audacity is in active Record mode - but should be inferred and acted upon when the Recording is in Pause mode.
  • The Pause button should be popped up when the "stop and do" is acted upon - and after the "stop and do" Audcity will be in ready mode and not paused.
    • Gale 05May15: If user depressed Pause then we could do what Steve and I suggest above (stop the stream and set cursor at the stop position but leave Pause depressed). Edits would be available because we were already stopped. I assume pressing Pause might leave Record or Play depressed but Stop would be disabled - but that would have to be discussed.

GUI Examples

TBP

Previous Feature Requests relating to this proposal

  • Full editing (including effects) while paused: (35 votes) more intuitive than having to Stop if you are thinking of hardware equivalents like a tape machine.
      Instead of pausing you could use the "Play/Stop and Set Cursor" shortcut (SHIFT + A by default). Then the cursor will be at the place you stopped just as if you had paused. You can change thet key binding for that shortcut in the Keyboard Preferences

Related Feature Requests relating to this proposal

  • No separate Stop button: press Play and Record to toggle start and stop (4 votes)
  • No separate Pause button: let Play and Record become Pause once depressed, can be distracting looking for/having to hit a separate button. (1 votes)
      Some users find recording starts quicker with a Pause > Record > Pause sequence that needs a separate button
      We obviously can't have both of these, I guess whichever one get's more votes wins if either one gets in
      actually we can have both via theming. The 'only' difference is the image used for button down.
  • Transport Menu:
    • Add "Play/Stop and Set Cursor (SHIFT + A)" (4 votes)
      • Peter 25Jan15: We do now have this in the Transport menu, but note that there is no corresponding button in the Transport Toolbar.
    • Rename to Play/Record so discoverable by novices (4 votes)