Proposal Play-at-Speed

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.

Problem

• 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

• Integrate Play-at-Speed with the scrubbing code, so that the slider can control the play speed in real time.
• Also support looped Play-at-Speed with dynamic varying speed.
• Also support cut-preview at speed with dynamic varying speed.
• Make the Play-at-Speed control resizable (like meter toolbars) so that greater precision in setting the speed is easy/possible.
• Negative Play-at-Speed
• 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

Prototype

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.

Checklist

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

Details

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