Hello everybody,
if click on a point of the song with ctrl, the song plays from this point. The Problem is since i have resetted my PC, the song plays forward if the mouse is on the right side and plays backward if the mouse is on the left side. For me this function realy disturbing. Does anyone know, how i can deactivate it.
Thanks
Best Regards
Andreas
You have put yourself in scrubbing mode - just press the Stop button to return to normality …
Hard to tell when you’re in scrub mode as there is no proper or effective visual cue 
There is a bug report for this - I have just added your tribulations here as a use-case.
See: http://manual.audacityteam.org/o/man/scrubbing_and_seeking.html
WC
Version 2.1.1 introduced some ESC key actions, such as aborting a zoom-in drag in the vertical ruler. Perhaps ESC should also always stop playback, including scrubbing, and recording, independently of keyboard preferences which may also assign that function to other keys like space. Perhaps this universal ESC key convention needs to be emphasized in the manual and tutorials for future versions.
I hope to see more ESC key actions in 2.1.3, such as, aborting all of the click-drag-release actions like draw and envelope and time shift tools.
A good start Paul (but only a start) would be to fix Bug #1053 http://bugzilla.audacityteam.org/show_bug.cgi?id=1053
where Gale suggest the left part of the Status Bar should say “Scrubbing” rather than “Playing” when in scrub mode (and possibly change to “Seeking” while in Seek mode). Plus as he also points out the central part of the Status bar message gives incorrect advice/information while in scrub/seek mode.
And fix Bug #1052: http://bugzilla.audacityteam.org/show_bug.cgi?id=1052
No visual indication whether CTRL has initiated scrubbing or not (to which Andreas’ experience in this thread was added yesterday as a use case).
I say “only a start” as I suspect that by itself it is a bit too subtle for most folk to notice stuck down there at the bottom.
I do think we need to provide also a much stronger visual cue to indicate scrubbing, what we choose can be open to debate after the upcoming release of 2.1.2. Personally I think I would like to see a Scrub-Play button added to the Transport Toolbar. The user would press this to go into scrub play mode (rather than using the current control and click, scrubbing would start at the current cursor position and of course just as now the user can change the cursor position to change scrub-central. The scrub-play button would be depressed in the toolbar while scrub play is active - and should be more obvious to the user to think of using the Stop button in the same Transport Toolbar to stop scrub-play.
And while we’re at it I would also like to see us fix Bug #991: http://bugzilla.audacityteam.org/show_bug.cgi?id=991
By conscious design Pause is not actionable while in scrub mode but the Pause button is not grayed out as it should be to indicate that it is inoperable, nor is the Transport>Pause command.
BTW all three of these bugs are rated at P3, sufficiently highly to warrant an obligatory mention in the Release Notes for a release - so we really should be putting some focus on fixing them.
Thanks,
Peter.
I’d like the escape key also to cancel the label edit mode, i.e. undo the creation of a label or setting the label back to its original content, before entering edit mode.
Thanks Paul
Robert
Thank you so much for your quick answers. Probably one of the two or three most important programs on my PC.
That makes sense, if we user ESC more widely.
As well as making it more obvious when you are (accidentally) in Scrub, I think it should be more obvious how to enable it. Yes it could be another Play button. It could also be a draggable bar of some sort, or a widget you could drag on the Playback cursor. Just about anyone could discover that.
Should you not be able to enable Scrub Play when already standard-playing, without having to click? Engaging the suggested Scrub Play button could do that, too.
I say yet again, there should be an option to disable backwards scrub. With that option on, when you move the pointer backwards, forwards play automatically starts from there. Then there is no need to press SHIFT and have to move the pointer to restart playback from that new point. I would actually use scrubbing then (sorry Paul, but I find scroll-scrub too “fiddly”). Even then I would still find dragging something to scrub far more intuitive.
Andreas, in case you don’t know, you can click in the Timeline above the blue waves to immediately forwards play from that click point. It’s like the old CTRL + click in the waveform, but you don’t need to press CTRL.
Gale
What Gale says …
I welcome suggestions for alternative user interface for scrubbing and seeking. The choices made for 2.1.1 may not have been best and I hope we can revise them. I will write more later.
Should you not be able to enable Scrub Play when already standard-playing, without having to click? Engaging the suggested Scrub Play button could do that, too.
That goes beyond user interface changes and would require more work to get the playback engine to cooperate.
I say yet again, there should be an option to disable backwards scrub. With that option on, when you move the pointer backwards, forwards play automatically starts from there. Then there is no need to press SHIFT and have to move the pointer to restart playback from that new point. I would actually use scrubbing then (sorry Paul, but I find scroll-scrub too “fiddly”). Even then I would still find dragging something to scrub far more intuitive.
Andreas, in case you don’t know, you can click in the Timeline above the blue waves to immediately forwards play from that click point. It’s like the old CTRL + click in the waveform, but you don’t need to press CTRL.
Gale
Scrub something. Move the mouse left, click, and move right again. Play restarts where you clicked. Is it good enough?
I don’t understand the reference to SHIFT which is not part of scrubbing interface any more.
Do you say you would use scroll-scrub if it were not “fiddly” or that you just don’t find it at all useful? Then don’t use it. I presume there is no trouble avoiding it. I think it is a nice option to have. A version of play that leaves the play head centered and scrolls the wave instead satisfies at least one old feature request, doesn’t it?
Part of that bug description is that you can’t click and drag to select audio during scrub, but the status bar suggests you can.
Maybe the real problem is that we should reenable click and drag to select during scrub.
The reason we don’t is that we need some way to switch between scrubbing and seeking, and decided on left click, among several not wholly satisfactory alternatives. I wanted to reject anything using a modifier key because it would conflict with the use of certain keystroke commands during playback, like ctrl-m to drop labels or shift-a to stop and set cursor.
My thinking now is that scrubbing and seeking should be controlled by mouse clicks in the horizontal time ruler, not in the track area. Though it could still be (as now) that seeking is a drag but scrubbing is not. Scrubbing could still change speed and direction in response to mouse motion events, no matter where the pointer goes.
Let us not forget too: http://bugzilla.audacityteam.org/show_bug.cgi?id=1079 “Scrubbing is stopped when a tool that is not Select is chosen”
The reason for that complaint: I make scrubbing and seeking available in selection tool only, because ctrl-click in the track area has other meanings in other tools, and while we might accept the forfeit of left click to select, I did not want to forfeit left click in other tools – so a tool switch would make change to seeking impossible, so it was better just to ban scrubbing when you switch. This reasoning isn’t pretty! Again it suggests to me that the clicks to scrub and seek might be better done in the time ruler, leaving all the other clicks and modified clicks in the tracks in whatever tools free to keep their old meanings. Then without that conflict, it would make sense to allow scrubbing in the ruler no matter what the tool is.
And fix Bug #1052: > http://bugzilla.audacityteam.org/show_bug.cgi?id=1052
No visual indication whether CTRL has initiated scrubbing or not (to which Andreas’ experience in this thread was added yesterday as a use case).
Do we make a new cursor that looks like a scrub-brush? Maybe that’s too “cute” but a cursor change would be nice. It could also become binoculars for seeking.
I say “only a start” as I suspect that by itself it is a bit too subtle for most folk to notice stuck down there at the bottom.
I do think we need to provide also a much stronger visual cue to indicate scrubbing, what we choose can be open to debate after the upcoming release of 2.1.2. Personally I think I would like to see a Scrub-Play button added to the Transport Toolbar. The user would press this to go into scrub play mode (rather than using the current control and click, scrubbing would start at the current cursor position and of course just as now the user can change the cursor position to change scrub-central. The scrub-play button would be depressed in the toolbar while scrub play is active - and should be more obvious to the user to think of using the Stop button in the same Transport Toolbar to stop scrub-play.
And while we’re at it I would also like to see us fix Bug #991: > http://bugzilla.audacityteam.org/show_bug.cgi?id=991
By conscious design Pause is not actionable while in scrub mode but the Pause button is not grayed out as it should be to indicate that it is inoperable, nor is the > Transport>Pause > command.BTW all three of these bugs are rated at P3, sufficiently highly to warrant an obligatory mention in the Release Notes for a release - so we really should be putting some focus on fixing them.
Thanks,
Peter.
It might be worth considering. But I assume if we change to a draggable bar or widget you may have to get the playback engine to switch to scrub seamlessly?
I forgot SHIFT was removed, but no for me I don’t want to have to move the mouse again after click. If that click happened to be the place I wanted there is no need for me to move the mouse again.
I know it is not fashionable to say it, and I don’t use fancy DAW’s, but the scrub-play in VLC would be (mostly) good enough for me to find the place I want, and certainly completely intuitive.
I just can’t get used to scrub play suspending when the playhead reaches the mouse pointer, and so constantly thinking ahead that I have to keep the mouse moving to prevent suspension.
No-one can do anything at suspension without moving the mouse again, so the only benefit I see in it is if you want to listen up to the pointer and stop. I’m sure that is very useful sometimes, but why force that behaviour on everyone, with no option or means to toggle what happens?
I could envisage that if we had no option for forwards play only (or if such option was off), but had a play-toggle, clicking the left mouse button when play was suspended at the pointer would restart playback in the direction it came from. Playback would continue until the mouse was moved and the playhead met the pointer again (or until the playhead reached the start or end of project).
If you were dragging with left mouse button down and play had suspended at the pointer, releasing the left mouse button would restart playback in the direction it came from.
If a “forwards play only” option was on, then the mouse click or release when play was suspended would play forwards even if the playback had been backwards.
Or we could have no play toggle. Just an option “Don’t stop when scrub play reaches the pointer”. Play suspends only when the playhead reaches the start or end of the project.
I quite like the play toggle idea, if it is feasible. But any of the above ideas would make a big usability improvement for me.
It is not useful to me personally, though I don’t oppose it. I only feel tempted to use it because I can’t live with play suspending at the pointer in standard scrub.
I do sometimes get it by mistake if I fumble-click. I would rather have it enabled it by holding a second modifier.
Indeed, in the absence of standard playback having continuous scrolling, but I think that should still be done.
Gale
If Enh: Allow keyboard to flexibly adjust the cursor or selection during playback or recording was fixed, the ability to drag-select during scrub would be less important than it is now - perhaps sometimes useful rather than essential.
I think we must retain a simple click in the Timeline, by default, plays from the click point to the end of the project, if a stop is not executed. No mouse movements should be allowed to prevent that.
Yes. But until then we could simply prevent tool changing when scrubbing was on.
Unlike the developers, I am not personally a fan of buttons changing icons for type of playback.
Or do you mean change the mouse pointer? But we would not want to do that if we ever allowed scrubbing in different tools.
I still like the idea of displaying the playhead as soon as scrubbing is on, before the pointer is moved for the first time. Is that possible?
Gale
Gale, it seems you just need the left click in the time ruler. What do you want scrubbing to do for you, that you can’t do by that means? I know you do not like backwards play, and you don’t like it that play stops at the cursor. (I thought it was good for scrub to do that as an aid to setting your selection boundaries by ear. Find the right stopping place, stop play, and click again). You don’t find scroll scrubbing useful.
What part of scrubbing does that leave? It does leave variable speed with mouse wheel and it does leave seeking by holding the mouse button down. So are you saying you like those new features but want an interface you like better?
I do not propose to eliminate any features of the time ruler, but perhaps some key-modified or double clicks can be used there to redesign the scrubbing user interface.
My strong advice would be to ignore use of the Timeline ruler for scrubbing - leaving the Timeline for QuickPlay and restricting scrubbing gestures to the waveform itself. This, for my money, will keep the interface cleaner (without you losing or removing functionality.
I disagree with Gale about removing backwards scrubbing, I definitely want to keep it (that’s how scrubbing worked on tape decks) - and I agree with Paul that if you just want forward play to find your audio, then the Timeline QuickPlay is ideal for that - it’s what I use most of the time.
But I still really would like a scrub button in the Transport Toolbar - and I do like Paul’s idea for a different cursor while scrubbing.
Peter.
Nowhere have I said that I want to remove it, only that forwards-only could be an off-by-default option. Yes of course, many may want the analogy with back and forth tape head movement.
The current method does have some advantages. We can scrub back and forward without holding the mouse button down. But for me, audio playing backwards is a distraction (I will not be exporting backwards audio). It’s a delay to finding the part I want. I can remove the delay if I drag-seek with mouse down, but then I lose the benefit of not having to hold the mouse down and I still have to move the pointer again to resume playback.
If we had a “forwards play only” option then for example, moving the mouse backwards by five seconds if I want to hear a point five seconds previous would simply play forwards from there. Two separate operations are saved. I do not need to click. I do not need to move the mouse again after moving the mouse back.
I could as I proposed live without disabling backwards play if there was a way to click to resume play when it suspended at the pointer. If you simply want to play forward from the spot you found, is click not easier than Stop and restart standard playback, or drag the mouse off the end of the project?
As you said, I can’t change speed that way nor drag-seek, which is sometimes nice. Yes, I really like the speed change. 
If there was “forwards scrubbing only” then when I want to play from a previous point I would not need to click as would be needed for Timeline Quick-Play.
With scrubbing I am in the waves and can see more easily “what I am doing” without the distractions of Timeline numbers, an extra playback cursor and a vertical white line (I know I asked for that vertical line, but that was because we removed Quick Play in the waveform).
Yes, but I may not have found the place for the boundary yet. Until I do, I must constantly worry about keeping the mouse moving forwards instead of concentrating on listening.
If we had play-toggle, I don’t need to stop play, only click and don’t move the mouse.
Yes. I want to go back to a previous place and hear from there with less physical effort than now. I want an option to never stop when the playhead reaches the pointer, or to be able to click to resume play when that happens.
I have some reservations, as Peter does. Mine would be the physical Timeline elements distracting me from the waveform.
Also fumbled single-click can easily become double-click or vice-versa. We don’t have many options for modified Timeline clicks - we already use CTRL and SHIFT with drag in the Timeline for Cut Preview and Loop Play respectively.
Gale
I remind you the downside of present choices is restricting scrubbing to the select tool. I would like it to work in the multi-tool. But too many mouse clicks are already taken to do other things in that tool.
I agree scrubbing should ideally work in Multi-tool. However I want my eyes to be focused on the waveform, not up as far as the Timeline.
Even if we don’t reinvent scrub by dragging on a separate “scrub bar” between Timeline and waves, you could click some widget on the playhead, or some button elsewhere to initiate scrubbing, rather than CTRL-click in the waveform. That was never very discoverable when it did Quick Play, and even now it is easy to miss the Status Bar messages.
Gale
I don’t understand why you were strongly opposed to having a “scrubbing tool” (the tried and tested solution in other applications) and then effectively gave us a “scrubbing tool” by re-purposing the “selection tool”. That seems to offer the worst of both options imo 
.
Had you accepted the tried and tested solution, making it fully accessible would have been trivial.
What Steve says - and I can’t for the life of me see why scrubbing shouldn’t work whatever tool is currently in effect 
The Play and record functions are entirely neutral as to the user’s tool choice - and what’s more you can change tool while Play or Record are active ! 
Peter.
And what disappoints me most is that we have now missed the opportunity to fix these scrubbing issues for 2.1.2 - so we will issue a second release with a sub-optimal implementation of scrubbing