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

From Audacity Wiki
Jump to: navigation, search
(No. Option-1 not back on the table.)
m (James moved page Talk:Proposal Action edits when in Pause mode to Talk:Completed Proposal Action edits when in Pause mode without leaving a redirect: done for 2.1.3)
(No difference)

Latest revision as of 18:43, 2 August 2017

July 2016

Stop and Do+

  • 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.

    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).

  • 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....
  • Gale: 04Jul16: I already understood what you meant, IF users actually find SHIFT + A, but I don't know if you can infer that users will always want to append record if they SHIFT + A then press Record again, even if they use an effect before record. If they stop in any fashion, what is the issue? The effect will already be available. What we are addressing, I thought, is users pressing Pause and/or trying to use the effect without pressing Stop.

    Also, what does Stop and Do when recording mean, given Peter said in 3) that we should not Stop and Do during recording?

    I thought Stop and Do meant making Effect Menu active when an input or output stream is still active or paused, then when user clicks an effect, stop the stream and set the cursor at the stop point. I would argue such a stop should depress the Pause button. If the user actually engages Pause before using the Effect Menu, then selecting the effect would stop and set cursor and leave Pause engaged. Releasing pause would remember whether it was playing or recording. So I think we need both "Stop and Do" and "Pause behaves like Stop".

    • Peter 07Jul16: The problem we are addressing 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. My original proposal was not explicit about that, I will add to it for clarity.
  • James: 04July16: Stop-and-Do+ is because I disagree with Peter. It should stop record too. To do that we need the smarter record that typically appends. Your 'pause stays down' is a further refinement. Under the hood there is a real difference between pause and stop. If we have exclusive access, in pause we own the sound card. In stop another app can take it. Stop-and-start is expected to click. Pause and unpause not. Your further refinement is doable. It makes it look visually as if you can do things in pause. I would still only convert a pause to a stop if we had to, in order to avoid the click. Another approach is to do the opposite and change 'stop' behaviour so that we never actually close the sound card (unless changing device or rescanning). We just divert the record/play callbacks to a do-nothing subroutine. This would stop clicks if done carefully, and give us monitoring continuously. This would also fix PULSE issues. It is what I do in AU14 TrackPanel. Possible concerns - do events queue up in hibernation? I don't know.
    • Peter 07Jul16: In the two years since discussing this at AU14 with Leland I have changed my mind on this and now agree with James that Stop-and-Do+ should also interrupt a Recording that is in Pause mode. I have updated the proposal page accordingly. I now think this makes perfect sense as the user could have paused the recording long ago, come back to Audacity and then finds themself wondering why they can't do stuff.
    • Gale 08Jul16: What do you support happening when user is recording then tries to perform a currently forbidden action? A dialog with "don't show again" option?
      • Peter 08Jul16: I support it doing exactly what it does now when the user is actively recording - all the illegal functions would be grayed out and unavailable as now. That in itself could be good enough as the user should be able to see that either the waveform is moving (with pinned record head) or the record cusor and vertical red line marker are moving across the waveform (un-pinned record head).

        But I would also support a no-can-do dialog with "don't show again" option - although ideally I would prefer it not to be dismissable with the "don't show again" - it may some elapsed time before the user makes the same mistake again, maybe weeks or months later. Provided, that is, that we can handle this without interrupting or corrupting the ongoing recording

  • Gale 05Jul16: I think on balance that Stop and Do is OK when recording. The user pressing Pause is unambiguous. The only questionable part is exploring the menus or using an effect shortcut by accident. When doing so there could be a warning (default yes and don't warn again) to always allow recordings to be interrupted by a "Do".

    I appreciate that Pause and Stop are different under the hood, but if we are to solve this intuitively I think Pause should stay down. Are you saying that if Pause stays down, then when we don't have to convert to Stop, we could actually leave the stream open and visible in the meters? And if we had to stop, the meters would go dead while Pause was still engaged? I don't think that is terrible because it shows when a click on resume might be expected.

    Leaving the sound card open on Stop seems to have a lot of advantages. It could be annoying if you want to use other applications which can take exclusive control of the device, and you found you couldn't play or record in them until you quit Audacity.

  • James 06Jul16: Yes, we can easily do a do-not-show-again dialog on (accidentally) causing a stop in pause-record. Yes, the stream could stay open with monitoring active until we do the (currently) forbidden action. Afterwards the meters would go dead while pause still engaged.

Options Table

Here 'FOP' will be used to mean an operation that is currently forbidden during pause, such as applying an effect. These are some of the components we can choose from....

  1. Some actions are forbidden when paused (both in Pause-Record and Pause-Play)
  2. No Pause Button at all. Stop is (always) stop and set cursor. And...
    1. Default for Record and Play buttons are to continue from position where left off, if can.
    2. Record and/or play cursor show their position clearly, even if not currently playing/recording.
    3. Stop keeps stream open and we micro-fade to avoid clicks.
  3. Pause pops up, if you do a FOP and...
    1. No warning it just does that.
    2. Default for Record and Play buttons are to continue from position where left off, if can.
  4. Pause does not pop up and...
    1. Stream Kept Open. (Monitoring stays on, no-click happens when starting and stopping)
    2. OR Stream Stopped if must. (Monitoring stops if stream stopped)
      1. As above with do-not-show-again warning.
    3. OR Stream Stopped if must AND restarted (but paused) after a FOP. (Clicks each time it happens. Monitoring is on in pause)

1 is what we have right now in Audacity. 2 is AU14 TrackPanel. 3 is DarkAudacity (not fully there yet) and is my stop-and-do+. 4 with 4.1 is (probably) Gale's preferred combination, with 4 with 4.3 as a second choice (Gale to confirm). 4.1 is too much for 2.1.3. 4.2 or 4.3 are very doable for 2.1.3.

  • Gale 06Jul16: Might 4.1 cause noise if software playthrough was on and monitoring always on? If there are use case drawbacks to 4.1 it could possibly be an on-by-default option. Is 4.1 the only way to fix the pulseaudio freeze problem?

    I don't understand the circumstances in 4.2 where we "must" stop the stream but "might" be able to "Do" and keep the stream open.

    In sum, I can't choose between the 4.x options until I am clearer on my questions. However Pause button retained and remains down on "Do" is my desideratum, even if 4.2 or 4.3 are implemented and not 4.1.

  • James 06Jul16: I think 4.1 is fine with software playthrough. It's probably the best way to fix pulseaudio. A less good way would be to make an assumption that say a start/stop every 3 seconds was OK, and rate limit start/stop (under pulse audio) to that, giving the driver time to start up and stop. In 4.2. the stream is open when you pause, and if you don't do a FOP it stays open, only closing if you want to do one of the FOPs. 4.3 is probably closer to what you want than 4.2. There will be a click before and after each FOP in pause. Monitoring will stop only for the time it takes for the FOP to complete - i.e. for the time the stream is closed. This will be a lot worse for pulseaudio, lots of starts and stops, so perhaps 4.2 if pulse audio selected.
  • Gale 06Jul16: From what you've written I can't discern any real advantage in 4.3. Does any pause stop in 4.3 whether doing a FOP or not?
  • James 07July16: In 4.2 monitoring stops. In 4.3 it continues (after the FOP completes, but not during the FOP). Also in 4.3 releasing pause will be clickless and without stream starting delay, because when you do stream will already be active, paused rather than stopped. In 4.2 (if you FOPped) it is actually stopped so no monitoring after the FOP and not 'primed' to play/record.
  • Gale 08Jul16: From your current description I will be first choice for 4.1 and second choice for 4.3. The drawback of 4.3 is the click on starting and completing FOP and the more demanding behaviour for pulseaudio. However it will be more obvious in 4.3 that the FOP caused the stream to be suspended. Relatively few users on Linux fall into the trap of trying to do FOP when the stream is active.

  • Peter 07Jul16: I'm really in favour of Option 3 above: Pause pops up, if you do a FOP and, No warning it just does that, Default for Record and Play buttons are to continue from position where left off, if can. I've always wanted Audacity to work more like my tape decks and restart from where the head is stopped currently. I like the fact that if you are overriding Pause that it pops up and you are effectively then un-paused. And although my original proposal was just for a warning (to advise and make the user press Stop if required) in the context of Option 3 I think it is totally unnecessary.
  • Peter 07Jul16: James, is there any chance that we could get this done for 2.1.3? It's been the top item of my three-wishes Wouldn't It Be Nice list for a long time now. Not only do other users get caught out by it, it still occasionally catches me out too ;-))

    I'd be more than happy to work on the testing, on W10 & Mac, and the Manual updates if you can find some time to do the devel work.

  • James 07Jul16: I am doing 3 for DarkAudacity for end of August. For it to work well I also switch RECORD to be record-beside and SHIFT-RECORD to be record-below. Current behaviour of Audacity is RECORD is record-below and SHIFT-RECORD is record-beside-ish. I added a new record-below icon and I retired the record-beside one (aka record-append). Of course technically I can do 3 for Audacity 2.1.3. I plan instead to feed agreed changes from DarkAudacity 2.1.3 into Audacity only in 2.1.4. I get DarkAudacity working the way I want, we push it out to some users to check, then team decides which changes should be cherry picked into Audacity in the next release. Happy to talk more off-list/off-wiki about why. If this were a P2 (enhancement) bug it would be different. That would expedite a change, and prioritise it enough even at the possible risk of holding up Audacity whilst we reach consensus.
  • Gale 08Jul16: Bug 1205 (P3) is borderline P2. Some users give up with Audacity on first encountering the behaviour. Making a click on the Record button do append-record is a big and controversial change. Really, I think what click on Record does should be a Preference.

    In 4.3, I now envisage pause might release during a FOP and re-engage after the FOP. This will align with when monitoring stops and restarts. The reason I think Pause should release at least when you finish the FOP is that if it doesn't, it will still look like a "bug" to those who were expecting to only suspend the audible stream in order to edit.

    It seems to me we need to decide if we want to do 4.1 for Audacity 2.1.4, which is the best solution for PulseAudio. *If* we do, what is the point in a temporary Stop and Do workaround for 2.1.3?

    • Peter: So, if we end up not doing this for 2.1.3 and put it off till 2.1.4 is there any chance we could as an interim measure just implement my initial suggestion in the Proposal, Option-1 pop up a warning/error message (dismissable or not so - I would prefer not dismissable). At least then the poor benighted user would get some idea of what was going wrong and how to escape.
    • James: Peter, lobby for 1205 to be a P2. It will lead to a better outcome all round. Better than a warning dialog.

Jan2015. Start a new section in Feb

Doing sections by month, hopefully this will save us work distilling arguments down. At some point the discussions we had in feb 2015 will be only of historic interest. Current discussions will be clearly separate.


  • James: what does 'armed' actually mean? As far as I can see Audacity can go straight into recording/playing without being armed.
  • James: an implementation detail is that at the moment play/record make a glitch sound on the headphones when you press them whereas pause release doesn't. That's a bug rather than an essential distinction and is because play and record re-initialise the sound card and portaudio cannot do that silently. This bug is also why on some machines that take a long time to reinitialise their sound cards record could be slower than releasing pause. On the new trackpanel there is no click as the sound card runs all the time once it has been started. This is also good for monitoring as that doesn't have to keep being restarted.
    • Gale 13Jan15: "Armed" means what you guessed in your longer paragraph directly above. If those practical reasons why people prefer to "arm" are resolved, then the reasons for a Pause button that keeps transport going are negligible (down to habit/use in other DAW's). Fixing those bugs also saves us fixing the problem that the play or record cursor carries on going for a while after Pause is issued, so that SHIFT + A then sets the cursor too far to right.<p> The reasons for a Pause button that toggles stop / restart from the stop point are still strong I think.

Restart position Play versus Pause

  • James: IF the distinctive difference in play/record cursor behaviour between pause and play/record is felt to be sufficiently important, we can add cursor setting menu commands that go back/forward one cursor set position.
    • Gale 13Jan15: Seems like an extra step for something that is built in now. If you were playing a selection it is probably just as likely you want to apply an effect/edit to that selection as trim the selection to start from where playback sets down.
    • Peter 13Jan15: many of our users (those who "get" the tape recorder idiom) get confused when using Stop during playback to find that when pressing Play that playing reverts to playing from where the current cursor position is rather than starting again from where they stopped (it catches me out from time to time).
    • Gale 13Jan15: Then I suggest we let those users use Pause to stop and set cursor and Unpause to resume. When they see Unpause does that, they should not expect Play to do same as Unpause.

The start/end of track buttons

  • James: The start/end of track buttons are low utility for their area. It would make more sense if they were advance/back by one marker where track ends are markers, selection boundaries are markers, and the last reached play/record position is a marker. Their navigation becomes a lot more useful then and it is easy to do.
    • Gale 13Jan15: Not sure. I agree those two buttons are of lesser utility but your idea could mean many extra steps to navigate to project start or end by that method.
      • Peter 13Jan15: I use those two buttons rather a lot, my workflow for capturing live webstreams usually involves using Timer Record with a 5 minute buffer at either end - so the ability to move to either end for trimming is very useful. I suppose though that I could teach myself to use the Home and End shortcuts. And given that these commands and shortcuts already exist I can see that these buttons in their current form could be viewed as redundant - and as such I do take James' pov that they are a comparatively expensive use of the Toolbar real-estate.
      • Peter 13Jan15: Also note that these buttons can sometimes cause confusion. Users who relate to the tape recorder idiom often expect these buttons to be "Fast Forward" and "Fast Rewind".


  • Gale 09Jan15: I am unclear if this idea applies to calling edits from shortcutstoo.
    • Peter 11Jan15: I definitely intend this proposal to apply to commands invoked from keyboard shortcuts too.

Action edits while playback is in progress

  • Gale 09Jan15: there is a secondary problem that some users try to edit without even pausing, just by calling an edit command (notice the active Edit Toolbar buttons when there is transport suggest this can be done). So we may want to consider "just stopping and doing the action requested" when playing, even if a pause transport function is removed. We should not "stop and do" when recording.
    • Peter 12Jan15: Steve and I discussed this offline prior to writing this proposal. His view, with which I strongly agree, was:

      "It may be possible to extend the auto-stop to work during non-paused playback, but this will require a great deal of thought and attention for the behaviour to be intuitive and non-disruptive, so is something that could be looked at *after* auto-stop in paused playback is implemented and thoroughly tested."

      • Gale 13Jan15: I agree it is secondary but it could speed up workflow. Goldwave, CoolEdit and Wavosaur all either infer stop or actually edit live while playing when an edit is called during playback. I find "infer stop" for edits during playback totally intuitive (as long as I don't press the wrong shortcut).
    • Peter 12Jan15: And yes I totally agree with Gale when he says We should not "stop and do" when recording - actually I'm not even convinced that we should "stop and do" while paused during recording.

Eliminating the pause button

  • James is in favor of eliminating the pause button.
    • Peter 12Jan15: What are the implications of this for enabling the user to continue record on the same track? Would we be forcing them to issue an Append Record, which is more complicated (compound) clicking than just pressing/re-pressing the Pause button or the "P" key? Or does your proposal mean that a while recording a press of the Record button will pause the recording and a second press restart it? I am concerned that this could be seen by many users as a regression - a move away from the tape recorder idiom.
      • Gale 13Jan15: I agree with that concern - many folk doing recordings will be using a tape machine or lifting an arm from a record player to change sides (i.e. pause).
    • James: In new TrackPanel, record at cursor is the default. The cursor is placed when you stop. YES this is different to what we had before. YES it is different to a tape recorder. Is it inconvenient? I don't think so. Many of our users have never used a tape recorder. Regressions are unintended bugs. This is an intentional purposeful change in behaviour. We don't have a graphic to 'cut the tape diagonally' for splicing it, nor force the user to wait for the glue to set. So we are already not true to the tape recorder idiom. We don't need to be a tape recorder. We need to be easy and intuitive to use. Just today someone has posted on feedback asking how they can get an unmixed project having stopped a recording and started recording again. I'd say mixing by default is the confusing behaviour.
      • Gale 13Jan15: Feature Requests shows that many users would find it more intuitive to unpause after edit and not (apparently) stop at all. If we can fix the problems that provide an advantage to Pause keeping the stream running, perhaps we should have a button that looks like Pause. Depressing that button does Stop and Set cursor if playback or record are going. Releasing it does play from cursor if it was playing when paused, or append records in the same track(s) if it was recording when paused. A Pause button is still widely understood IMHO and could be a better way to keep recordings on one track than forcing Stop to set cursor.

        My impression is that the camp of restart playback from start or end point is evenly split (*not* most folk want to restart from the end). I'm guessing we may hear about that when RTP is released. If we have a Pause button like I suggest, and if we keep Append Record as I think we will, why can't Stop stop where you started? Then if people want to mix their subsequent recordings they can press Stop after recording. If they want to do an advanced punch-in at the stop point in another track, they can press Pause.