Proposal Play-at-Speed

From Audacity Wiki
Revision as of 11:31, 2 January 2022 by PeterSampson (talk | contribs) (Proposed Feature: looped Play-at-Speed with dynamic varying speed. - done)
Jump to: navigation, search
Proposal pages help us get from feature requests into actual plans. This proposal page is about making the Play-at-Speed slider real-time and stretchy.
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.
bug 133 is an enhancement request for this and has more details.


  • Play-at-Speed only plays at the speed set when Play-at-Speed was started.
  • It is difficult to precisely set a play speed.

20-21 July 2018: These two problems are essentially addressed now.

Proposed Feature

  • Done.png Integrate Play-at-Speed with the scrubbing code, so that the slider can control the play speed in real time.
  • Done.png Also support looped Play-at-Speed with dynamic varying speed.
  • ToDo.png Also support cut-preview at speed with dynamic varying speed.
  • Done.png Make the Play-at-Speed control resizable (like meter toolbars) so that greater precision in setting the speed is easy/possible.
  • ToDo.png Negative Play-at-Speed
  • ToDo.png Remove the Play-at-Speed play button. This will close Bug 815. Instead:
    • All play is play-at-speed
    • The transcription toolbar gains presets for x1 and user chosen speeds.
    • New projects open with the preset set at x1.


A possible Play-At-Speed with presets



Here's a prototpyed play-at-speed showing:

  • Negative as well as positive speed
  • Loop play as a toggle (also works for play backwards)
  • Play icon changes for preset speeds like 1/2.
    • Custom icons for 3x, 2x, x1/2, x-1/2, x-1.

This particular implementation preserves the two play buttons. The one on the transport toolbar always plays at x1, but you can then drag the slider to change the speed. The one on the play-at-speed toolbar remembers its speed.


  1. What is the purpose of the feature? - More controllable play-at-speed
  2. What is the relative importance 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) - The feature uses the same real estate and/or gives the user the option of giving the slider more/less real estate that they previously could not do.
  3. Does the feature have modes, and if so how easy are the modes to get out of? (stuck in a mode) - No.
  4. Does the feature have invalid states that can be greyed out? - No change from previous Play-at-Speed.
  5. What is the factorization of the feature? (e.g. pin/unpin can operate on its own, independent of scrub/seek). - Resizing and real time are separate factors.
  6. What are the justifications for 'novelty' in the design? (e.g. RSI free operation, lack-of-precision in conventional sliders). - Resizability gives greater precision
  7. Is VI use integral? (e.g. labels added a label editor dialog, essential for VI, useful for non ). - VI users will probably use the numerical controls.

Developer/QA Backing

  • James Crook
  • Peter Sampson


  • We should consider having an easy click-stop at x1, x2 and x3.