Bugzilla – Bug 802
Recording is interrupted/halted by clicking in Timeline when one project window is open
Last modified: 2018-08-20 11:45:24 UTC
When you are recording if you click in the Timeline the recording is stopped - and playback is started from that point. This is erratic and wrong behavior as it could cause a user to interrupt and perhaps lose an irreplaceable recording. In contrast, pressing the Play button (or the Play at Speed button) while Audacity is recording does not perform a similar interruption.
I don't like the behaviour much but it goes back to at least 1.3.3 and it is called a "Quick Play" feature. Marked as P2 Review. My suggestion would be that stopping a recording by clicking on the Timeline should require a CTRL-click. CTRL-click in the waves does stop the recording and start playback.
My suggestion is that nothing short of an explicit click on the Stop button or equivalent keyboard command should stop recording.
(In reply to comment #2) I agree with Bill. What exactly does bug type "Review" mean? Can this be fixed before Audacity 2.1 is released?
(In reply to comment #1) >I don't like the behaviour much but it goes back to at least 1.3.3 and it is called a "Quick Play" feature. "Quick play" is perfectly reasonable when Audacity I s inactive or even when playing. It really is unacceptable behavior when a recording is in process - it's 1.3.3. provenance is not the issue - it was wrong then and it remains wrong now. I agree with Bill and Steve.
(In reply to comment #2) Bill wrote: > My suggestion is that nothing short of an explicit click on the Stop button or > equivalent keyboard command should stop recording. So do we also stop CTRL-click in the waves (surely a deliberate action by the user) stopping recording and playing from there? Isn't that a feature (do a quick "scan record", hear something you want to keep, then CTRL-click to stop recording and play it)? The issue was about accidental left-clicking in the Timeline, as I understand it.
(In reply to comment #3) > What exactly does bug type "Review" mean? Can this be fixed before > Audacity 2.1 is released? P2 requires RM to consider if the issue should be fixed/implemented or not, regardless of the Importance "type". "Review" indicates there is no consensus this is a bug. My impression is that the developers intend the feature to behave as it does now i.e. they did not overlook that it stops a recording.
(In reply to comment #6) The Play button is disabled during recording, so I think it is clear that playback mode is not intended (other than overdub playback) while a recording is in progress. I think that it is a valid point that Ctrl+Mouse click cannot be easily done by accident, so although I personally don't like that behaviour I agree that it is an issue that should be properly reviewed before changing. On the other hand, destroying a recording by clicking on the time line is clearly a much greater risk. Clicking on a waveform during a recording is allowed and a user might do that to select a specific part of a recording while the recording is in progress. There is no clear indication that if they click a fraction higher on the screen that the recording will stop. If we have consensus that clicking on the time line should not stop a recording, then I would be happy to fix that.
(In reply to comment #7) Steve wrote: > If we have consensus that clicking on the time line should not stop a > recording... It appears that we have unanimous agreement that clicking in the timeline should not cause recording to abort. That part of the bug should now be fixed in Revision: 13797, but please test on all platforms because mouse pointers can have inconsistent behaviour cross-platform.
Created attachment 527 [details] disable scrubbing during recording Given that scrubbing will cause a recording to abort, I don't see any sense in it being enabled during recording. The attached patch disables scrubbing during recording and gives a status message to that effect if scrubbing is attempted.
Should the description say instead 2) Ctrl-click anywhere in the timeline Because I do not see it with unmodified click. This (mis)behavior is not new in 2.1.0. So it is not just new scrubbing but also old click to play.
> it is not just new scrubbing but also old click to play. Accidental click in the Timeline is my concern, but no-one I know of complained before now. Quick-Play goes back to at least 1.3.3. CTRL-clicking or CTRL-dragging in the waveform almost certainly is deliberate, not accidental, so if we don't allow either type of scrubbing in the waves when recording, we deny some ease of use.
(In reply to comment #11) This is not "complaining" - it's bug-reporting (and a bug that is regarded as pretty serious by most of QA). It's taken me until now to track down what has caused me several times over the past years to interrupt important unrepeatable recordings. It's only recent destruction-testing for 2.1.0 that led me to stumble on the actual cause.
(In reply to comment #0) Confirmed fixe on W7 64-bit##] r13797 in latest nightly "2.0.1 r13800 22Dec14" The related Ctrl+click in the Waveform still interrupts and aborts Recording
r13707 seems to work as intended for single projects on OS X Yosemite and Mavericks. > This is not "complaining" - it's bug-reporting It's a review of an issue. > Confirmed fixe on W7 64-bit##] r13797 in latest nightly "2.0.1 r13800 22Dec14" But only fixed for single projects. Extensive discussion a few years ago on -devel deemed it was OK for explicit play in one project to stop recording in another project. So we need to review if Timeline left-click in one project should stop recording in another project. I think so, given r13707. The posted patch "bug802-scrubbing.diff" compiles on Windows and blocks CTRL-click and CTRL-drag in a single project from stopping a recording. I'm 0 on that. If we want that, I think CTRL-click in the waves and hover over Timeline should have a corresponding Status Bar message "Quick-Play disabled during record". I'm -1 in r13707 and this patch on Quick-Play and Scrub Play being disabled when recording is paused. If this is about irreplaceable recordings being lost, the user lost them as soon as they pressed Pause.
(In reply to comment #14) Yes. only fixed for single projects, probably the most prevalent usage. we (and in particular Leland) said we would come back and examine multiple project behavior in more detail after 2.1.0 release. >I'm 0 on that. If we want that ... Gale, you wrote in the -quality discussion that you wanted this (albeit grudgingly) all the rest of QA wanted it unanimously - that made it a pretty clear consensus which is why Steve went ahead and made the patch, so I totally fail to understand why you are complaining about it now. I really don't understand why you go on to say "I think CTRL-click in the waves and hover over Timeline should have a corresponding Status Bar message "Quick-Play disabled during record"" because, at your bidding, no one has blocked Ctrl+Click in the waveform from interrupting and halting recording, though most of us on QA think that it should. So for you to say at this stage that you are -1 on this patch is disingenuous to say the very least.
To be clearer than I was, for consistency with r13797, I think that left-click in Timeline in one project should *not* be allowed to stop recording in another project. Sadly it is not currently clear enough that click in Timeline is a playback command, so that reason should apply to multiple projects too. (In reply to comment #15) > >I'm 0 on that. If we want that ... > Gale, you wrote in the -quality discussion that you wanted this (albeit > grudgingly) all the rest of QA wanted it unanimously - that made it a pretty > clear consensus which is why Steve went ahead and made the patch, so I totally > fail to understand why you are complaining about it now. Because it is not clear enough that Timeline is a playback tool, I wanted left-click in Timeline to be disabled during recording. Steve did that in r13797. I disagree that left-click in Timeline is disallowed from stopping recording and starting playback in a paused recording, because the recording is already lost. But if no-one wants to code that I'll have to live with it. I have never wanted CTRL-click in waveform to be disabled during recording. Because of the way user enables CTRL-click in the waveform, it is not identical to left-click in Timeline. It is harder for most people to CTRL-click by accident, and CTRL-click is an easier method of quick-playing when you need to keep your eye on the waves to decide where to click. If we still allowed CTRL-click when recording then we have at least given those who want to start playing a recording without stopping it a way to still do that i.e. we have not completely removed an existing feature (that you call a bug). > I really don't understand why you go on to say "I think CTRL-click in the > waves and hover over Timeline should have a corresponding Status Bar message > "Quick-Play disabled during record"" because, at your bidding, no one has > blocked Ctrl+Click in the waveform from interrupting and halting recording > though most of us on QA think that it should. If you were to compile or look at the attached patch "disable scrubbing during recording" you would see that it does disable CTRL-click quick-play during record. It makes no sense to me to disable scrub play and quick-play but only have a Status Bar message for disabling scrub-play. Steve is quite capable of committing his attached patch even though I am only 0 on it. I do think he should correct the partial Status Bar message.
(In reply to comment #6) Whys is this bug still marked as "Review"? Gale wrote earlier: " "Review" indicates there is no consensus this is a bug. My impression is that the developers intend the feature to behave as it does now i.e. they did not overlook that it stops a recording." It is clear from here and the even lengthier discussion on the closed area of the Forum that the majority of QA consider this to be a "bug" - a design oversight, an impact that the original developer of Quick-Play did not forsee or consider. Furthermore, Steve has submitted a patch for this bug which has been tested on all three platforms - so surely this particular bug should be marked as "Fixed". If there are issues arising that may be subject to "Review" such as whether or not Quick-Play should be capable of interrupting a Paused recording then that should be the subject of a separate new "Review" Bugzilla entry. I am loath to start work on correcting the Quick-Play sections of the Manual unless and until #802 is marked as "Fixed" and definitely in for 2.1.0.
(In reply to comment #16) Gale wrote: > I do think he should correct the partial Status Bar message. A status bar message may be used to provide the user with pertinent information about the current application status. It is not intended to provide a full "status report" about the application or even a full description about the control under the mouse pointer. It is my opinion that long detailed descriptions in any part of the user interface are counter productive. There is strong evidence to support the idea that the greater the verbosity, the less likely users are to read it. Gale wrote: > Steve is quite capable of committing his attached patch Yes I am, but at present it is far from clear whether the current "scrubbing" feature will be enabled in Audacity 2.1.
(In reply to comment #17) So far we have only heard from QA. If a developer actually comments that Quick Play was never meant to stop recording, then this should be changed to "Repeatable". I have not tested the attached patch "disable scrubbing during recording" on Mac. Steve's commit r13797 has been tested by me on Mac and so has been tested cross-platform. The whole issue of to what extent users should be allowed to accidentally stop their recording is a "review", given there is no consensus about it yet. Whether CTRL-click in waveform should be allowed to stop a recording is also a "review" IMO, because it is a different issue to that indicated in the bug title, which says "Recording is interrupted/halted by clicking in Timeline". In other words, the attached patch does not belong here, or the issue title has been widened after the event. Steve himself marked his r13797 commit as a "partial fix for bug 802" so clearly the bug is not fixed - you can click the Timeline in another project to stop recording. Since there have been no -1's on Google Code against the commit, I currently expect it to stand and I would envisage demoting this to P4 for the unfixed part of this issue.
(In reply to comment #18) I can certainly see a discrepancy between adding Status Bar messages for how to use spectral selection but not for CTRL-click (or for why it doesn't work). The rationale for having a Status Bar message for failed scrub play (a new feature) but not for failed Quick-Play (a feature established for many years) is unclear to me. Perhaps neither should have a Status Bar message - that's up to Steve.
(In reply to comment #19) Gale wrote: "... clearly the bug is not fixed - you can click the Timeline in another project to stop recording." The reporting of this bug was only about the behavior in the Timeline in a single project. It is well known that there are many things that one can do in a second project to impact behavior in the first, including just pressing the Play button - but that is far broader than the scope of #802 Gale wrote: "The whole issue of to what extent users should be allowed to accidentally stop their recording is a "review", given there is no consensus about it yet." Which means that the correct place to discuss it is on -quality and not here. Gale wrote: Whether CTRL-click in waveform should be allowed to stop a recording is also a "review" IMO, because it is a different issue to that indicated in the bug title, which says "Recording is interrupted/halted by clicking in Timeline". In other words, the attached patch does not belong here, or the issue title has been widened after the event." Gale, may I remind you that it was you yourself who broadened this out to include Ctrl+click in the waveform very early in this thread. It is indeed as you say "a different issue to that indicated in the bug title" and thus should really have its own bug report.
(In reply to comment #21) (In reply to comment #7) Revision: 13797 fixes the bug as currently described in the bug title and in the steps to reproduce. It does not fix the issue for multiple open projects. As Leland described, there are many problems with Audacity's handling of multiple open projects, and r13797 does not address those issues. That will hopefully be addressed post version 2.1. Revision 13797 does not address the wider "review" aspect of recording being aborted without the user explicitly stopping the recording. I have closed this bug (as currently stated) as "fix made", and we can open new bugs for the remaining issues. This bugzilla entry has clearly become much longer than is desirable, so I think better to discus those remaining issues elsewhere and just post concise summaries on bugzilla. Of course, if anyone strongly disagrees with closing this (802) bug, they may reopen it, though with over 20 comments already I think closing this bug and opening new issues as necessary would be better.
(In reply to comment #22) Those promoting issue 802 have now decided it is only about Timeline clicking when one project window is open. Clearly the original bug title was not specific enough, so I changed it from "Recording is interrupted/halted by clicking in Timeline" to "Recording is interrupted/halted by clicking in Timeline when one project window is open". This is the most common case. Clearly the commit log message that this was a "partial fix" for bug 802 does not accord with Steve's statement "Revision: 13797 fixes the bug as currently described in the bug title and in the steps to reproduce". Clearly the new decision about the scope of 802 means it is RESOLVED - FIXED, so I made it so. This discards the attached patch which was off-topic to issue 802 and did not have consensus.
(In reply to comment #23) Gale, it is somewhat fatuous and unnecessary to change the title of this particular bug - practically every bug reported in Bugzilla is about the actions within a single project with one project window open! And that was certainly my intention when originally reporting this particular bug - it was you yourself that decided to broaden this to encompass multi-project behavior in comment #14. It is well known now, but yet to be investigated fully, that actions in a second project window can impact activities and behavior in the first project. Leland has pointed this out publicly and decided that we should shelve such investigations and fixes until after 2.0.1. When those investigations take place no doubt we will be raising further Bugzilla entries for them and issuing rxxxx patches to fix them.
Peter, this bug is correctly closed RESOLVED-FIXED. As we have or will have a bug about the related and residual lower priority issues with multiple projects, retitling this bug removes any plausible reason for reopening this P2 issue and having a P2 to deal with. Gale is in charge of the bugtracker, and whilst he needs to aim to keep everyone happy, it's ultimately his choice as to how pedantic to make the bug titles.
(In reply to comment #25) Before retitling, anyone who actually did halt their recording by Timeline-clicking in another window could have visited this bug and legitimately argued the bug was not fixed. The basic problem is insufficiently signposted/misleading presentation of the Quick-Play Timeline feature. Given the intensity of feeling Peter and Steve had about accidental Quick-Play in Timeline, I genuinely thought allowing recordings to be halted by Timeline-clicking in another project was an oversight. I still think it's a (P4) oversight - anyone affected would argue P1 no doubt - but I let the bug be closed to keep the peace. Now we have a "better fix" https://code.google.com/p/audacity/source/detail?r=13861 that has not been commented here. It looks like that commit is aiming to improve "insufficient signposting" which will be good, nonetheless that commit is not wholly cosmetic and therefore I *must* REOPEN and change status back to "DEVEL - FIX MADE" to allow testing of the commit.
Understand, but reserve right to not agree, with reason for reopening. Per logic of my comment #25 I'm reducing this from P2 to a P4 as it is only the residual issue that can be relevant.
(In reply to comment #26) I have been extensively testing r13861 on W7 64-bit and I confirm that it fixes this issue on W7. And not only does it fix the issue for the confines of a single project it also fixes the use-case of multiple projects that Gale brought up earlier. I.e. start recording in Project-1, switch to Project-2 and try clicking in the Timeline - result: Timeline is shown as inactive on P2 as indicated by the helpful hover-text and the recording in P1 continues unhindered. Martyn wrote recently on the commit log for r13797: "Change looks good to me and should stop some heartache. Thanks Steve, this should stand. It is good that the whole ruler-clicking thing is disabled. I don't think paused projects are an issue, let's stay at what we have. The multi-project issues are not directly related to this so will be discussed elsewhere."
*** Bug 385 has been marked as a duplicate of this bug. ***
