Talk:Proposal: Improvements to Scrubbing - Phase-3

From Audacity Wiki
Jump to: navigation, search

James's checklist

Gale, thanks for taking this to the talk page, so that the main page can be clear and not a mix of different options
  • What is the purpose of the feature? - To find precise locations/positions in audio more easily/quickly. Subfeatures (may) allow for seguing straight into an action, e.g. find and then play (cueing variants) using essentially the same UI.
  • What are the relative importances of the different features in it? (this is used to justify having a large button, a small button or just a menu item, for example) - Still being debated. One view is that variable speed play (which we call scrubbing) is higher importance than jump-playing (which we call seeking). Reconfiguration of the scrubbing interface is lower importance than day to day use. Single-shot seek/scrub is higher importance than alternating seek/scrub.
    • Gale 17Aug16: Does Paul think alternating Seek / Scrub is lower importance? If we want it, there should be a seamless method e.g. by using a keyboard modifier.
    • James 17Aug16: I don't know what Paul thinks. I think being able to alternate is surely lower priority than being able to single shot, even if only slightly so, since without it you can still do two different single-shot actions. I think you're right about the modifier. The button is not suitable for on the fly alternating scrub and seek (even though the main page suggests using it) since you have to move the mouse to the button to use the button. A keyboard shortcut would work for on the fly changes, and could be either a toggle that changes the state, or it could be a modifier, active whilst held down.
    • Peter 18Aug16: Working with the just Scrub Bar (and without the Scrub Toolbar) it is currently (2.1.3 alpha GUI) very easy to alternate between Scrub and Seek -albeit you must start off in Scrub and then move to "temporary seek" but it's still very easy,
  • Does the feature have modes, and if so how easy are the modes to get out of? (stuck in a mode) - Currently yes, it has modes. Usually SPACE will be used to exit a mode. ESC will work to but undoes the change in cursor position.
    • Gale 17Aug16: Preserving the editing cursor or selection (which might be changed by the user during Scrub) is a feature, not a bug. SPACE on exiting Scrub is not doing SHIFT + A Stop and Set Cursor, but completely discarding selections. SHIFT + A itself only preserves selections before the playback position. There should arguably be some way for Stop and Set Cursor to Select Left and Right edge at playback position, not just left.
    • James 17Aug16: I think this is a good point that has bearing on 'the factorisation'. If scrubbing/seeking finds a point accurately, there is still a (big) question as to what you do with that point. Using it to set left/right edge of selection are natural candidates. So too is setting a region centred on that point. Perhaps also splitting the audio at that point, or dropping a label at that point. I suspect a good solution is to (a) have some memory of the previous selection. (b) Always make scrubbing/seeking set left and right edge of selection to that point (c) have new operations that do things with the current selection - for example make a label from it and then revert to the remembered previous selection, or make a selection including the current and previous selection... and so on.
      • Gale 18Aug16: Oops, in my 17Aug16 comment above, I should have said that SHIFT + A only preserves selections after the playback position (or within the playback position). If the playback position is after the selection, SHIFT + A discards any selection.
    • Peter 18Aug16: For most people using scrubbing is a way of finding a particular point of interest (as James' first point in this list clearly states). Therefore it is entirely appropriate that the normal stopping methods when scrubbing/seeking (Stop button etc.) move the cursor and playhead to the current scrub/seek position. It is also good that we provide the ESC/Escape to enable users to abort from scrubbing/seeking and to retain their pre-existing cursor position.
      • Gale 18Aug16: It's not appropriate to remove pre-existing selections entirely, only to adjust them. We can move one edge of the selection to the current playhead position without removing the other edge.
  • Does the feature have invalid states that can be greyed out? - No
  • What is the factorisation of the feature? (e.g. pin/unpin can operate on its own, independent of scrub/seek). - Pin/Unpin. Seek/Scrub. Single-shot/Multi.
  • What are the justifications for 'novelty' in the design? (e.g. RSI free operation, lack-of-precision in conventional sliders). - Mouse up x-coord input from mouse is justified by (a) RSI concern (b) operation of wheel at same time. The large 'slider' is justified by the need for precision.
  • Is VI use integral? (e.g. labels added a label editor dialog, essential for VI, useful for non ). - No.
    • Gale 17Aug16: Probably an opinion rather than a fact.
    • James 17Aug16: I guess a question needs answering about what actions depend on seeing the cursor position on screen. With scrubbing you can't tell whether you are to the left or right of the pin without seeing the screen. The audio playing won't always help you enough. You also can't see the play speed when you use the mouse wheel. Paul is looking to do more keyboard operation of scrubbing, and I think there is a strong case that making it good for VI users is additional work that has not specced in this proposal.

Peter's musings

I have long been thinking that we can avoid the complication of having both Scrubbing AND seeking by combining them into a single function

  1. with the widget close to the playhead playback is slow (scrub)
  2. as you move it further away the sped climbs to 1x and the 2x (maybe 2,5x max) - still scrub
  3. then as you move further away from the playhead the scrub turns into a seek (audio at speeds of greater that 2-2.5x is not really discernable.
  4. as you move the widget back to the playhead, or the playhead catches up with the widget, the speed behaviours step back through steps 2 and 1.

Bug 1423 - a familiar scrub

I think there are better solutions to the problem of doing a single scrub or single seek than the solution proposed in Bug 1423. Swapping the gestures will just mean that seeking (rather than scrubbing) now has to be explicitly cancelled, e.g. with ESC.

Peter 12Aug16: or more properly stopped by use of: Stop button, Transport>Stop command, Spacebar shortcut or pressing the active Seek key.

The design problem is that there are FOUR modes:

  1. - A single seek session which ends.
  2. - A single scrub session which ends.
  3. - Alternating seek-and-scrub sessions, which can end.
  4. - Alternating scrub-and-seek sessions, which can end.

Instead of having both a seek button and a scrub button we could have a single button that is either seek or scrub. A drag that starts in the scrub ruler (i.e the strip under the QP timeline) initiates scrubbing or seeking depending on the state of that button. When we mouse up, the scrubbing or seeking ends. This gives us 1 and 2.

Peter 12Aug16: I'm liking this single button idea. But it does mean that the Scrub Bar must be present for Scrubbing or Seeking to be available. Personally I like that - but Gale was adamant that he wanted to be able to scrub without the scrub bar, having the scrub widget run in the Timeline. I much prefer the total separation of the Scrub Bar and the Timeline. But remember you still need a mechanism to hide/display the scrub bar - unless that is you always have the Scrub Bar and it is not dismissable.
  • Peter 13Aug16: Overnight thinking:
    1. The logical place for such a single button would be the Transport Toolbar (or later as one of your multi-buttons)
    2. We could dispense with the Scrub Bar altogether - when Scrubbing/Seeking is active then the Timeline belongs to the Scrubbing and Quick-Play is inhibited. When Scrubbing/Seeking is inactive then the Timeline belongs to Quick-Play.
  • James 13Aug16: There are many possible choices. I don't think that button merits being Transport Toolbar button in size. I'd have preferences "enable scrubbing", "enable seeking". If either are enabled, the scrub ruler (i.e. the strip under the QP timeline) shows. If both are enabled, the scrub/seek button shows too. If the scrub/seek button is present, it's on the timeline, beside the pinned/unpinned button. There is room. The scrub toolbar (the one that held three buttons) is gone, and there's no little ruler button anymore as the scrub ruler presence is controlled by the "enable scrubbing" and "enable seeking" preferences.
    • Peter 13Aug16: Hmmm, preferences like that would work a treat for me. Would you have the default for both be "off" or "on" - I would choose "off" - but probably we want "on" for discoverabilty. It would be good to have a right click menu on the buttons to be able to turn them off too I'm thinking. I like the idea of putting the button in the Timeline above the TCP alongside the pinned/unpinned head button. I'm not clear what you mean by "scrub time-strip shows" is that just the Timeline (and in which case with scrub or seek enabled then Quick-Play would be inaccessible) or is is something new? Or is it the Scrub Bar by a different name just managed by the presence or absence of the Scrub/Seek buttons, with no separate Scrub Bar button (I like that idea).
    • Gale 13Aug16: 1423 is P4, so not mandatory to address it now, though the reason it's there is that some (many?) users will never buy into our scrubbing unless a technique familiar from other apps is available. The suggested changes seem quite major. If no Scrub Bar, how do we give people something tactile to drag? I understood from Paul that people may want to switch on the fly between seeking and scrubbing, so that might be a consideration. I'm really asking if this is for 2.1.3 now, in which case I'll have to read and think about this properly, and probably bug 1423 should be P3 and invite some sort of user feedback in the release note?
    • James 13Aug16 Gale: These ideas (single scrub/seek button etc) are NOT for 2.1.3. Peter: I've clarified wording.

A shortcut key can change the state of the button, and we can do that in-flight. This gives us 3 and 4. We also have a preference option that allows mouse-up-and-down in the scrub ruler to change the button state from seek-to-scrub or vice versa. That gives another way to switch modes in flight using mouse, which might be more convenient. When we eventually finish such a sequence (e.g. by mouse up outside the scrub ruler) the scrub/seek button reverts to our preferred starting state (seek or scrub).


With this scheme (as described so far) we never have to ESC out of a scrub or seek. In my own flow I would probably be only using seeking, and it would work well for that. The design does also support those users who want to alternate scrubbing and seeking. I think this is enough. I don't think we need more (the RSI free variant).

Peter 12Aug16: the ESC is explicitly provided as the one way for the user to retain their previous cursor position or selection (Gale explicitly wanted to be able to do that) otherewise stopping scrubbing/seeking leaves th cursor at the current scrub position (many of us wanted that).


Gale has in the past stressed the importance (to RSI) of scrub (item 3) being possible without mouse down. I personally disagree. I think the mouse up modes are unhelpful, and they run the risk of trapping users in a state which they might not know to SPACE or ESC out of (though the stop button will help). However we can do the RSI free version too:

For RSI free operation, we have a preference. If set, you have to click and release in the scrub bar to initiate scrubbing or seeking. Now scrubbing or seeking will continue until you explicitly end it, e.g by ESC or a click outside the scrubbing bar. You can switch from RSI free seeking to RSI free scrubbing (or vice versa) using the state shortcut, or by clicking-releasing in the scrubbing bar.

This scheme puts scrubbing and seeking on the same footing. It is easy to do one-off seeking or scrubbing. It is easy to chain them, starting from either. RSI free operation (if it is wanted) is available for both seeking and scrubbing, not just for one or the other.

Peter 12Aug16: Steve wrote last year (see below) "Moving the mouse pointer stretches a "rubber band" between the indicator position and the current mouse position, The length of the rubber band indicates the playback speed, When short, playback is slow. When long, playback is fast."
  • Extending that idea we could combine scrub and seek into a single gesture whereby when short playback is slow when long the scrub changes to seek rather than just a pure speed change. You can't make sense of scrubbed audio when going faster that 2-2.5x at best.
  • And I do like the idea of having to hold down the left mouse fror scrub/seek and that relealsing it then stops the scrub/seek - nice and simple, no chance of "getting stuck".


Reduced physical effort to use scrubbing - Phase-3

Gale: No-one else seems to care about this, but 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. An option for forwards play only is one possible solution. There is a discussion of this at http://forum.audacityteam.org/viewtopic.php?p=286530#p286530.

Playing through the Scrub

1) Gale wrote above: "I want to go back to a previous place and hear from there with less physical effort than now."

  • Peter 11Aug16: this is relatively straightforward but only if you are using the Scrub Bar. With the Scrub Bar yon easily select where to start scrubbing from and then you can slide the widget along the Scrub Bar, click again and Scrubbing moves to start from there.
    • Gale 14Aug16: Unfortunately the same problem remains. You have to move the pointer yourself after the click at the new point in Scrub Bar. Yes you can click in the Timeline, but then you are out of Scrub. As you say, you can't move the scrub point by clicking in the waveform, but that is (rightly) so because we allow changing the selection in the waveform when Scrub is active.

2) Gale wrote above: "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."

  • Peter 11Aug16: This is relatively easy to achieve now that the cursor position moves to the current scrub point when scrubbing is stopped. Simply make a single click on the Play button in the transport toolbar - or make two presses on the spacebar (one to stop scrubbing, the other to start Play) - or click in the Timeline above the Stop point foa a Quick-play.
    • Gale 14Aug16: The whole point of this request, which Robert J.H. also supports, is for continuous playback, so you can hear the context following the place of interest.
      • Peter 14Aug16: But the problem with that Gale is that that is not what most people in the world would recognize or define as "scrubbing" - playthrough like this, as you request, is "playing" (try asking Koz who has a lot of professional experience in this area). It doesn't of course prevent a developer from adding this as an extra optio to the current two modes of Scrub" and "Seek" - a mode called "Scrub and playthru" or whatever - but I'm puzzled as to how when it "plays on" that the user gets to retain or mark their "point of interst" that their scrub found.
        • Peter 14Aug16: Ah, now that I've done some more research I realize that what you are asking for here Gale is commonly referred to as "Cueing" and not "scrubbing" - I see no reason why should not provide cueing as well as scrubbing (and seeking) but we should not confuse the issue by referring to it as "scrubbing".
        • Gale 15Aug15: Could you provide some relevant links please to what Cueing would do. I am not sure it covers my first request (click to seek to another scrub point then have scrub play forwards without further initiation).