Difference between revisions of "Proposal Play-at-Speed"
From Audacity Wiki
(Presets image.) |
(Progress.) |
||
| Line 4: | Line 4: | ||
* Play at speed only plays at the speed set when play at speed was started. | * Play at speed only plays at the speed set when play at speed was started. | ||
| + | ** [https://github.com/audacity/audacity/commit/17ca54ad4bb3280a05fa68702125a005f2264822 Progress has been made on fixing that]. | ||
* It is difficult to precisely set a play speed. | * It is difficult to precisely set a play speed. | ||
Revision as of 21:21, 20 July 2018
| 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.
Proposed Feature
- Integrate play at speed with the scrubbing code, so that the slider can control the play speed in real time.
- Make the play at speed control resizable (like meter toolbars) so that greater precision in setting the speed is easy/possible.
- Remove the play at speed play button. This will close Bug 815. Instead:
- All play is play-at-speed
- The transcription toolbar gains a toggle button that toggles between x1 and a user chosen speed.
- New projects open with the toggle toggled to x1.
A possible Play-At-Speed with presets
Checklist
- What is the purpose of the feature? - More controllable play-at-speed
- 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) - 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.
- Does the feature have modes, and if so how easy are the modes to get out of? (stuck in a mode) - No.
- Does the feature have invalid states that can be greyed out? - No change from previous play at speed.
- What is the factorisation of the feature? (e.g. pin/unpin can operate on its own, independent of scrub/seek). - Resizing and real time are separate factors.
- What are the justifications for 'novelty' in the design? (e.g. RSI free operation, lack-of-precision in conventional sliders). - Resizability gives greater precision
- 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.
